JSON Escape

The JSON string grammar is narrow about what it forbids inside quotes. A double quote would end the string early, so it must become `\"`. A backslash starts an escape sequence, so a literal one must become `\\`. And any character below U+0020 - the C0 control characters, including tab, newline and carriage return - is not permitted raw and must be escaped. That is the entire mandatory list.

Everything else may appear literally. Single quotes need no escaping, because JSON strings are always double-quoted. Forward slashes need none either, although `\/` is legal and you will sometimes see it, a habit inherited from embedding JSON inside HTML `<script>` blocks where the sequence `</` could terminate the tag early. Accented letters, CJK characters and emoji are all valid raw UTF-8 in a JSON string.

The five control characters that have short forms - `\b`, `\f`, `\n`, `\r`, `\t` - are conveniences. Any of them could equally be written as a `\u` escape, and the remaining control characters have to be.

This distinction is the source of most confusion in this area. Escaping takes the *contents* of a string and makes those contents safe to sit between quotes. It does not add the surrounding quotes. Stringifying takes an entire JSON value and turns it into a string literal, quotes included, ready to be a value inside another JSON document.

So if you paste `{"a": 1}` into an escaper you get `{\"a\": 1}` - a fragment you would place inside quotes yourself. Paste the same thing into the JSON Stringify tool and you get `"{\"a\": 1}"`, which is a complete, valid JSON string value.

Which one you want depends on what you are assembling. If you are building a string by hand in a code editor and already typed the opening quote, you want escaping. If you are nesting a whole payload as a field inside another payload, you want stringifying.

JSON's `\u` escape carries exactly four hex digits, which addresses only the first 65,536 code points. Anything above that - most emoji, historic scripts, many mathematical symbols - cannot be written as a single `\u` escape. It has to be encoded as a surrogate pair: two `\u` escapes that a parser recombines into one character.

This is why a rocket emoji becomes `\ud83d\ude80` rather than a single escape. The two halves are meaningless alone and must stay adjacent and in order. If a pipeline truncates a string by character count, it can cut between the halves and leave an unpaired surrogate, which some parsers reject outright and others turn into a replacement character.

The practical advice is to leave non-ASCII characters unescaped wherever the transport is UTF-8-clean, which today is nearly everywhere. Escaping them is only worth doing when you have a genuinely ASCII-only channel to survive, such as an old email header or a legacy system that mangles high bytes.