Selection of five formats
The core of this tool is the function to switch the processing direction between "Escape (Character to Code)" and "Unescape (Code to Character)", and the provision of 5 code formats selectable during escaping.
When "Escape (Character to Code)" is selected from the "Processing Mode" in the control panel on the left side of the screen, the input plain text is converted into the Unicode escape representation of the specified format.
The following 5 formats can be selected from the drop-down menu. The first is \uXXXX (JS/C++/Java). This is a format that represents characters as 4-digit hexadecimal numbers in UTF-16 code unit increments.
The second is \u{X...} (ES6). This is a format introduced in ECMAScript 6 for JavaScript, where the Unicode code point of the character itself is specified directly in hexadecimal within curly braces.
The third is &#xXXXX; (HTML Hexadecimal), a format that writes HTML numeric character references used to display characters on web pages in hexadecimal.
The fourth is &#DDDDD; (HTML Decimal), which represents the same HTML numeric character reference with a decimal value. The fifth is %uXXXX (Legacy URL).
This is a percent-encoded format used in legacy JavaScript built-in functions like escape(), which is different from the current standard percent-encoding.
Note that %u and 4-digit u formats operate on units.
When a user types sentences into the input text area, the program scans the string character by character based on these selected formats and renders the results in the output area on the right in real time.
The screen update does not involve any communication to the server, and everything is executed synchronously by JavaScript within the browser's memory.
Japanese and ASCII
This tool provides an "Escape ASCII characters too" switch to control how to distinguish and escape non-ASCII characters such as Japanese and ASCII characters such as alphanumerics and half-width symbols.
In the Unicode specification, characters with code points less than 128 (0 to 127 in decimal) are classified as ASCII characters.
By default, this switch is off, so even if half-width alphabets or numbers are included in the text, they are output as is without being converted.
This allows usage such as escaping only the Japanese parts and comparing code representations while leaving the ASCII parts intact.
On the other hand, turning this switch on will escape all input characters according to the selected format, regardless of the code point evaluation.
Furthermore, a "Make alphabetic parts uppercase" switch is also implemented. This is a function to toggle whether the hexadecimal representations (a to f) within the escape codes are output in uppercase (A to F).
For example, if the character "あ" is escaped in the \uXXXX format, it becomes \u3042 if the switch is off, but if the switch is on, the alphabet portion is capitalized in the output.
Note that this "Make alphabetic parts uppercase" switch is hidden from the control panel when &#DDDDD; (HTML Decimal) is selected as the format.
This is because the decimal notation does not contain alphabets, making the capitalization process itself meaningless. By hiding invalid setting items through UI linking logic, it provides intuitive operation.
The ASCII < 128 and uppercase settings are properly retained.
Emojis and surrogates
When escaping characters that exceed the Basic Multilingual Plane, such as emojis (e.g., supplementary ideographic planes), appropriate conversion based on character code specifications is required.
This tool scans strings using character iteration and extracts the full code point via codePointAt, while also supporting UTF-16 code units where appropriate.
Inside JavaScript, strings are managed as sequences of 16-bit code units. For instance, consider the case where the emoji "😊", which is also included in the sample text, is input.
The code point for this emoji is U+1F60A. In UTF-16 representation, a combination of two code units known as a surrogate pair—a high surrogate (0xD83D) and a low surrogate (0xDE0A)—is used to represent this supplementary character in memory.
When converting emojis, the selected escape format determines whether code points or surrogate code units are emitted. The standard \uXXXX and legacy %uXXXX formats operate at the UTF-16 unit level, escaping 😊 into \ud83d\ude0a and %ud83d%ude0a respectively.
Conversely, the \u{...} brace notation and HTML numeric character references (&#x...; and &#...;) operate directly on Unicode code points, producing \u{1f60a}, 😊, and 😊.
Both English and Japanese interfaces share this unified code point conversion logic.
Both locales output backslash formats using a single literal backslash in text output, ensuring that generated escapes are clean and ready for direct insertion into source files or documentation without unnecessary double-escaping.
Restoration of mixed notations
In the Unescape mode, which restores characters from code, the tool provides a reliable mechanism to restore text containing any of the five supported escape formats back to standard plain text.
The restoration core performs a robust single-pass regular expression replacement across the original input text. It matches \u{...}, \uXXXX, &#x...;, &#...;, and %uXXXX simultaneously in a single scan.
Each matched token is parsed directly to its corresponding character, and the resulting character is never subjected to recursive or multi-stage re-evaluation.
For example, an escaped literal sequence such as \u005Cu{41} decodes once to the literal text \u{41}, rather than being recursively expanded to the letter A.
When a user pastes escaped codes into the input text area, the process scans the entire text. Each matched substring is converted to either its UTF-16 code unit or full code point according to its format specification.
Because replacement is strictly limited to matched substrings from the initial input, plain text surrounding the escape sequences remains untouched.
Handling of invalid values and non-matches
Both the encoding and unescaping routines enforce an exact input limit of 100,000 UTF-16 code units. If this threshold is exceeded, processing is refused immediately with an inline error message and no partial output is emitted; this boundary mitigates excessive processing workloads rather than guaranteeing execution time or total browser memory limits under all operating conditions.
Furthermore, input sequences do not always fall within valid Unicode ranges, requiring strict validation rules for malformed values.
In the Unicode standard, the maximum representable code point value is defined as U+10FFFF. When an out-of-bounds code point exceeding 10FFFF or a parsed numeric value that exceeds the safe range is encountered in code point formats, the conversion logic intercepts the condition and registers an error, whereas malformed or negative character sequences not matched by the conversion regular expressions are left as literal text.
For HTML numeric entity conversions, the parser and encoder reject the NUL character (0), standalone surrogate code point values (D800 to DFFF), and all C1 control characters (80 to 9F), while valid surrogate pairs (such as emojis) are combined and accepted as valid scalar code points.
Whenever an error occurs, any previous output in the textarea is cleared immediately and an error notification is displayed below the field.
On the other hand, text segments that do not match any of the five supported escape regular expression patterns, or syntactically incomplete sequences (such as an incomplete \u12 or an unterminated numeric entity like あ without a semicolon), are not treated as conversion errors.
These unmatched strings are safely preserved as-is in the output, allowing developers to process mixed documents without altering surrounding plain text or code comments.
Copying and differences from HTML, JSON, and URLs
This tool is equipped with UI operations to enhance the convenience of input and output, and has clear functional boundaries distinguishing it from other specialized data format conversion processes.
The screen features a button to instantly swap the processing direction, a Clear button to reset both input and output fields, and a Load Sample button to verify specific behaviors.
When copying output, the application awaits the completion of the asynchronous clipboard API before indicating success, and displays an explicit error notification if clipboard access is denied by browser permissions.
As a functional boundary to note, this tool is strictly designed to perform direct conversions between characters and their Unicode numeric representations.
For example, while it can generate HTML numeric character references, it deliberately does not implement browser HTML parser replacement tables, named HTML entities (such as & or "), or HTML sanitization.
Likewise, when preparing data for JSON, it escapes individual characters but does not wrap strings in double quotes or escape backslashes within string literals as required by JSON syntax specifications.
Furthermore, the %uXXXX format represents the legacy escape format historically used by JavaScript's escape() in older web browsers and should not be confused with standard UTF-8 percent-encoding used in modern URLs.
When complete URL percent-encoding or full JSON serialization is required, dedicated tools designed for those specifications should be used.
The text conversion algorithm runs locally in the browser without executing eval() on user input, though standard site assets, analytics, or third-party resources communicate over the network independently.
Additionally, the direction swap control is enabled only when valid non-empty output exists; if an encoding operation expands the text beyond the 100,000 code unit input threshold, the resulting output cannot be swapped back and decoded in a single pass.