Unicode Escape Converter

The Unicode Escape Converter takes any text you give it and rewrites every character as its Unicode escape sequence; the letter A becomes \u0041, an accented é becomes \u00e9. That representation is most useful when you are debugging text that looks right but behaves wrong: a name that won't match in a database, a string that breaks a JSON parser, or a label that renders as a blank box. Seeing the underlying code points tells you exactly which characters are present, including ones the eye cannot distinguish.

For web and software work, it helps you spot the difference between a normal hyphen and an en dash, a straight quote and a curly one, or a regular space and a non-breaking space (\u00a0) that snuck in from a copy-paste. It is also handy for inspecting mixed-script input (say, Latin letters mixed with Cyrillic look-alikes) and for preparing escaped string literals to drop into source code or config files.

Beyond development, it suits data-prep and admin checks: confirming that a CSV cell or a form field contains only the characters you expect, or examining text pulled from a PDF, an e-book, or an archived document where invisible or unexpected characters often hide. If your text fits cleanly in the ASCII range, the escapes will simply confirm that.

The process is direct: paste or type your text into the input, press Run, and the escaped version appears in the output, which you can copy or download. Everything runs in your browser; on this site the text is not uploaded, and nothing persists once you close the tab. There are no accounts, quotas, or server round-trips involved.

Under the hood, the tool walks your text one UTF-16 unit at a time and emits \u followed by four lower-case hexadecimal digits. The escapes are concatenated with no separators and no spaces, so "Hi" becomes \u0048\u0069. A character outside the Basic Multilingual Plane, such as most emoji, is written as a surrogate pair: 😀 becomes \ud83d\ude00, which JSON, JavaScript, Java and C# all read back as the original character.

It is worth being clear about what the tool does not do. It only encodes text into escapes; it does not decode escapes back into characters, and it offers no toggles for upper-case hex, the \u{...} brace form, \xXX, HTML entities, or code-point spacing. It is a one-direction inspector, not a configurable codec.

Characters above U+FFFF, such as most emoji, need two escapes. An emoji like 😀 (U+1F600) comes out as \ud83d\ude00, a surrogate pair, rather than as one five-digit code. The pair round-trips correctly through JSON and JavaScript strings; if you need the code point itself, for a Unicode table or the brace form \u{1f600}, combine the pair yourself. A value from \ud800 to \udbff is always the first half of one.

Combining characters are listed individually, which is accurate but can surprise you. An accented letter typed as a base plus a combining mark shows two escapes, while the same letter as a single precomposed character shows one. If you are comparing strings, normalize them first, because identical-looking text can produce different escapes.

Finally, the output has no delimiters, so long runs of escapes form one unbroken string that is hard to scan by eye. For careful inspection, work with short selections rather than pasting an entire document at once.

Start by confirming the obvious: a quick spot-check that a known character maps to the code point you expect (a plain space is \u0020, a non-breaking space is \u00a0) tells you the tool is reading your input as you intended. Count the escapes against your character count; a mismatch usually means combining marks, or an emoji or other character above U+FFFF, which takes two escapes. A pair whose first half is between \ud800 and \udbff is one such character, not two.

When the escapes are headed into a programming language, paste a small sample back through that language's own parser to verify it decodes to the original text, since escape syntax differs between JavaScript, JSON, Python, and others. For anything official, financial, or legal (identifiers, regulated records, or contract text), do not treat the escaped output as proof on its own; verify the underlying characters manually, ideally against a second source or a trusted normalization step, before acting on what you find.