Encoding and character sets
Decode Unicode escapes and HTML entities
Tools to use
Readable text has become sequences beginning with a backslash or ampersand. The original characters may be intact, merely represented for another format. But these sequences do not share one decoder: Unicode escapes, HTML character references, and URL percent encoding follow different rules.
Use あ, an emoji, and a short HTML-like string to inspect decoding. Treat outputs as text, not executable HTML or JavaScript. Even code-looking results need not be executed. Keep track of the source format throughout the experiment.
Decode \u3042 into one character
\u3042Unicode decoding produces あ. Encoding it yields \u3042 or \u{3042}, depending on the selected notation. Both refer to a character, but a destination format may not accept both. Distinguish JSON string syntax from JavaScript code-point escapes.
A log displaying \u3042 may simply serialize あ using escapes. Determine whether the actual value contains six literal characters or one character rendered that way by the logger. The notation alone does not prove corrupted storage.
One emoji can require two \u sequences
\u{1F600}
\uD83D\uDE00The first names one code point; the second represents its UTF-16 surrogate pair. Decoding either separately yields 😀. Two escape sequences do not mean two emoji. The distinction between visible characters and UTF-16 units also appears in escaped notation.
A lone \uD83D fails as an unpaired surrogate. Do not shorten the notation by removing half a pair or truncating it to fit a limit. Splitting representation units creates invalid data. Any truncation policy must define its unit explicitly.
& is a character reference for &
Tom & Jerry
<b>hello</b>HTML entity decoding produces the text Tom & Jerry and <b>hello</b>. The tool is not meant to execute that tag or render it as bold. Inspecting restored text differs from inserting HTML into a DOM; successful decoding is not a safety approval for insertion.
Named decoding currently covers amp, lt, gt, quot, apos, and nbsp, alongside numeric references. It is not the full HTML named-reference catalog; unsupported names remain unchanged. A reference-looking sequence left in output may indicate unsupported syntax rather than damaged data.
One pass over &lt; does not produce <
&lt; → < → <The first pass restores & to &, leaving <. Another pass produces <, but a second pass is not automatically correct: the original may intentionally discuss the notation <. Determine the serialization layers rather than decoding until no escapes remain.
Different formats can be nested, such as HTML text inside JSON. Parse the outer JSON to obtain its string separately from decoding HTML references. A single broad replacement can alter required quotes or delimiters. Define expected values at each stage with a small example.
Percent escapes and numeric references need different decoders
Unicode: \u3042
HTML: あ / あ
URL UTF-8: %E3%81%82HTML numeric references name a code point in decimal or hexadecimal, while URL percent sequences represent UTF-8 bytes. Different digits need not mean different characters. Select the tool from the source format; if that format is unknown, check the producer instead of guessing from appearance alone.
Unicode decoding here supports \uXXXX, \u{X}, and \xXX, not every string-literal escape such as \n or \t. Use JSON Formatter for a complete JSON document rather than treating this field as a JSON parser. Respecting unsupported syntax preserves meaning better than forcing a successful-looking conversion.
The destination still has its own output rules
Decoding advances the investigation, but placing the result into HTML text, attributes, JavaScript, or URLs still requires context-appropriate handling. Escaping once is not universally safe everywhere. Reassess how the destination interprets the string whenever its context changes.
Report the original sequence, decoder, number of passes, and resulting text. 'One HTML-reference layer restored the intended &' is more actionable than 'fixed garbling'. Trace where the extra layer arose; correcting that boundary prevents recurrence better than repeatedly converting until the display looks right.
Is the visible backslash data or representation?
A log showing \u3042 may represent an original あ escaped only for display, or six literal characters supplied by a user. Whether decoding is needed depends on which layer was copied. If reading JSON, identify the parsed value first. Before adding replacements to make a log look readable, check whether a JSON parser has already interpreted its escapes.
HTML character references have the same issue. To display the literal example <, the source may contain &lt;. Decoding twice produces < and changes the example you intended to show. Decode according to known representation layers, not repeatedly until something looks readable. The tool cannot infer the input's processing history.