If you aim is just readability for the developer side of things and you don't actually want newlines in the string data, then yes, check if your tooling supports soft wrapping. It's also possible for tooling to render soft linebreaks wherever a \n
is in a JSON string, but none of the tools I use actually do that.
Note that JSON5 supports spanning the writing of a string across multiple lines by placing a \
at the end of a line that continues on the next line. This does not actually put a newline character at those places into the JSON string, though you can manually add a \n
to get that.
Otherwise, if you actually want the string data to contain a newline where you insert an unescaped newline character in the JSON string, the answer is "no, you can't*".
By Douglas Crockford (the creator of JSON)'s JSON specification, a string cannot contain any of "the 32 control codes".
If you want something more precise, the RFC document (8259) for JSON says:
All Unicode characters may be placed within the quotation marks, except for the characters that MUST be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).
So no unescaped, literal carriage returns or line feeds. You can only put a newline (line feed) in JSON strings by using escape sequences (\n
), which most tooling will not render as a visual line separator (though that's not to say that they couldn't- just that they usually don't).
* Technically, there is a newline character defined in Unicode that is allowed as an unescaped literal inside a JSON string: U+2028 (see also What is unicode character 2028 (LS / Line Separator) used for? TL;DR "unambiguous newline character"). But it's a relatively obscure codepoint, and your mileage will vary on whether your developer tools will render it as a line separator, or as something else (like �). I just tested with VS Code, and it issues a warning about "unusual line separators", and renders it as �. Also, not just the dev tooling, but since this is actual content, it will be what the rest of the system sees (Ex. machinery that renders the text to a user). Your mileage will vary there as well.
That is to say that this is not really practical as a workaround.
Fun fact: U+2028 is supposedly valid in JSON strings, but not in JavaScript, and some JavaScript bundler tools like Webpack have to do escaping to "put JSON in JS" (here).