Escape and unescape text — HTML entities, JavaScript strings and JSON strings

Element text only has to survive the parser looking for tags and entities, so “&” and “<” are the characters that change meaning, and “>” is escaped as well because old parsers treated it inconsistently and it costs nothing. An attribute value has to survive all of that plus the quote that closes it. Paste the sample above and switch the context toggle: in text mode the double quotes come out untouched, and in attribute mode they become &quot;. Drop the text-mode result into an attribute and you get <b class="loud"> ending early, with “best” read as two more attributes.

You need it in an attribute, and only because you may not know which quote the surrounding template used — inside a double-quoted attribute a bare apostrophe is harmless. It is written &#39; because &apos; is not in HTML 4: it is defined in XML and in HTML5, so a modern browser handles it, but anything parsing your markup as HTML 4 passes it through as five literal characters, while the numeric reference has been understood by everything since the beginning. Note that no escaping saves an unquoted attribute, which HTML still permits: in <input value=hello world> the value is “hello” and “world” is a second attribute. Quote your attributes, then escape for the quote you used — or for both, which is what the attribute context here does.

JSON is a strict subset, and the gaps are where things break. JavaScript has \' , \v, \0, \xHH, \u{1F600} and line continuations; JSON has none of them. JSON has \/ , which JavaScript does not need. JSON forbids single quotes as delimiters outright, and forbids raw control characters inside a string, so a real line break must be written \n. Try it: put \v into the JavaScript unescaper and you get a vertical tab; put the same text into the JSON unescaper and you get a sentence telling you JSON has no such escape and that \u000B is the JSON spelling.

JavaScript strings are UTF-16, so characters above U+FFFF are stored as a pair of code units — 😀 is \uD83D\uDE00. A lone surrogate is one half of a pair with no partner. It is a perfectly legal JavaScript string and a perfectly illegal Unicode one: TextEncoder replaces it with U+FFFD, a fetch body may reject it, and it cannot be written to a UTF-8 file as it stands. You can produce one here in one step — unescape \uD83D on its own in JavaScript mode — and the result carries the warning. It is the usual cause of a string that was truncated at a fixed byte count and now displays a replacement character.

Because that is the JavaScript rule: an escape the language does not recognise loses its backslash and keeps the character. It is worth knowing precisely because it is silent — a Windows path written "C:\temp" quietly becomes C:<tab>emp, and "C:\qemu" stays readable while "C:\new" does not. The unescaper here says so in a note rather than hiding it. JSON, by contrast, refuses unknown escapes outright, which is the whole reason JSON survives being passed between languages.

It writes “<\/” instead of “</”. Inside an inline <script> block the HTML parser is still looking for the closing tag, and it finds “</script>” even in the middle of a string literal — so a JavaScript string containing that text ends your script early and dumps the rest onto the page. “<\/script>” is the same string to JavaScript, because \/ is an unknown escape that resolves to /, and invisible to the HTML parser. The same trick is why the JSON mode offers \/ as an option.

No. Escaping is a per-context transformation, and it is only correct for the context you chose. Text escaped for element content is not safe in an attribute, and neither is safe inside a URL attribute — href="javascript:…" contains no character this page would touch. Nothing here is safe inside a <script> block, or inside a CSS value, or inside an unquoted attribute. Escaping at the right boundary is a real and necessary defence; escaping once and reusing the result everywhere is how the bug gets in. Escape at the point of output, in the context of that output.

Because this site already has a page that does it properly. Percent-encoding has one question that dominates everything else — encodeURI or encodeURIComponent — and the URL encoder answers it by showing you which characters your own input is treated differently by, along with the “+ means space” form-data rule. Reproducing half of that here would give you two pages competing to answer the same question and neither doing it fully. Use the URL encoder when the destination is an address; use this page when the destination is markup or source code.

The full HTML5 list runs past two thousand names, which is not worth carrying in a page budget. This one knows the Latin-1 block — every accented letter from &nbsp; through &yuml; — plus the common punctuation, currency, arrow and mathematics names such as &mdash;, &hellip;, &rsquo;, &euro;, &trade;, &rarr; and &ne;. Numeric references are handled in full, in both decimal and hexadecimal, for every code point that exists. Anything it does not recognise is left exactly as it is and reported by name, rather than silently deleted — the exact count is printed under the result.