But newlines can appear in JSON anywhere whitespace is allowed otherwise.

Yes, you can say “we will avoid this by never generating JSON with newlines.” But why would you do that when you can easily pick a delimeter that’s guaranteed by the spec not to appear?

I’ve often used the jsonlines format for application logging, though I didn’t have a name for it until today.

I appreciate this format because, as a log file, I can use all of my standard tools to work with it (grep awk etc.). Since it’s a text file, I can use standard text editors to view and search the contents.

Since my application is the one that’s creating the log file, newlines will not appear or will be escaped.

I can often accomplish my goal without parsing the objects, but when I need to, I can break out powerful tools like `jq` or RecordStream to query the contents in a structured way. I can also treat the log file as a streaming or archived data source and process it using database technologies like Redshift or Elasticsearch.

I can’t think of another format that would be more convenient. I have worked with log file formats that are actual XML or JSON documents, and they are inconvenient in practice. I can’t think of another format that would be more convenient than this one for structured application logging.

Lots of other tools work on a line by line basis.

But newlines can't appear in JSON-Lines which is what this is really based off of.