🧰 UtlKit

String Escape/Unescape Tool: How a 25-Character Input Becomes 27, 45 and 45 Characters After JavaScript, HTML and URL Escape, with the 9 JS, 5 HTML and Percent-Encoded Modes and Round Trip Rules Explained

Paste a 25 character string with an ampersand, quotes and angle brackets: the tool returns 27 characters after JavaScript escape, 45 after HTML escape and 45 after URL escape, with six modes and round trip inverses, all in your browser.

Strings break when they cross systems. A double quote inside a JavaScript string, an ampersand inside an HTML attribute, a space inside a query parameter: each destination has its own dangerous characters and its own way of neutralizing them. The String Escape/Unescape tool converts a pasted string into the safe form for that destination and back, entirely in the browser: nothing is uploaded and nothing leaves the tab. It works in six modes, three targets in two directions: Escape JavaScript, Unescape JavaScript, Escape HTML, Unescape HTML, Escape URL and Unescape URL. Take one 25-character input, a greeting with an ampersand, a colon and a quoted phrase inside angle brackets. After HTML escape it measures 45 characters, after URL escape it also measures 45, and those two 45-character results are different strings, which is the whole point.

Six Modes: Three Targets, Two Directions

JavaScript mode rewrites 9 of the 128 ASCII codes into two-character sequences: backslash, double quote, single quote, newline, carriage return, tab, backspace, form feed and the NUL code. Against the 25-character example only the two double quotes change, so the output keeps the ampersand and the angle brackets untouched and measures 27 characters; a string with a real tab and a real newline comes back with a literal backslash-t and backslash-n in those places. HTML mode converts exactly five characters: the ampersand into a five-character reference, the two angle brackets into four-character references, the double quote into a six-character reference, and the single quote into a numeric reference. URL mode is percent-encoding. Every escape has an unescape twin, and every conversion runs on the paste, with no server round trip.

The 25-Character Example, Three Destinations

Write the example out plainly: a greeting, an ampersand, a colon, and a quoted phrase wrapped in angle brackets, 25 characters in all. JavaScript escape adds one backslash before each of the two double quotes, 27 characters total. HTML escape replaces the single ampersand with its five-character reference, the two double quotes with their six-character one, and the pair of angle brackets with four-character references: 25 plus 20, landing at 45. URL escape percent-encodes the four spaces, the ampersand, the colon, the two double quotes and the two angle brackets: ten single characters become ten three-character percent sequences, and the total also lands at 45, a coincidence of this particular input. Three destinations, three answers, and the input is never changed in place: the tool always writes a fresh string into the output pane.

URL Escape: What Percent-Encoding Keeps

encodeURIComponent keeps 71 of the 96 printable ASCII characters untouched: all 62 letters and digits plus nine symbols, the exclamation mark, the single quote, the two parentheses, the asterisk, the dot, the minus, the underscore and the tilde. Everything else becomes a percent sign plus two hex digits. That is why it is a component encoder and not a URL encoder: run it on a full 53-character address with a query string and the slashes, the colon, the question mark and the equals sign all become %2F, %3A, %3F and %3D, producing a 75-character component, https%3A%2F%2Futlkit.com%2Ftools%2Fstring-escape%2F%3Fq%3DTom%20%26%20Jerry. When the question is one piece of a URL versus the whole URL, the URL Encoder/Decoder splits that decision explicitly. In the other direction, decodeURIComponent rejects a malformed sequence such as a dangling %E0 with a thrown error, and the tool catches it and shows the message instead of a half-decoded string.

Choosing the Mode for the Destination

The rule is destination first. Code that will be read by a JavaScript parser wants JavaScript escape; text or an attribute value that will be parsed as markup wants HTML escape; a query parameter wants URL escape. The neighbors cover the edges: the HTML Entities Encoder/Decoder works in named and numeric references, so a no-break space becomes   and an ellipsis becomes …; the Base64 Encoder/Decoder moves binary-ish payloads out of the text channel entirely; and the Hex UTF-8 Base64 Converter shows the same bytes as hex, UTF-8 text and Base64 when the question is what the bytes are, not how to quote them.

Where Escaped Strings Meet the Rest of the Toolset

Escaping rarely happens alone. When the escaped output is going into a JSON payload, pasting it into the JSON Formatter either parses cleanly or points at the exact character that broke it. When the input came from a clipboard full of invisible characters, the Whitespace Cleaner makes the tabs and line breaks visible before any escape decision is made, so a backslash-t in the output is a tab you sent, not a surprise.

Round Trips and the Double-Escape Trap

Every escape in the tool has an inverse that walks the same 128-code table backwards: JavaScript escape then JavaScript unescape returns the original string unchanged, and the URL pair round-trips too, hex pairs included. The one-way street is double escaping. Run HTML escape twice and the ampersand inside the reference itself gets escaped, so the result renders as the visible text of a reference instead of the character it names, and undoing it takes two unescape passes, not one. The failure mode is not the escaping itself but applying it twice, or once in the wrong mode. And when the problem with a string is its structure rather than its characters, the escape tools are the wrong instrument: the HTML Format guide covers the formatting side of the same document.

Related Tools

Frequently Asked Questions

Why does the HTML escape mode convert the ampersand before any other character?

Because all five references the mode writes, &, <, >, " and ', start with an ampersand of their own. In a single left to right pass, converting the ampersand first means the four references written afterwards are placed once and their built in ampersand is never scanned, so the 25 character example expands by exactly 20 and lands at 45. Any other order re escapes the references on the fly and the same input comes out far longer.

My JavaScript escape only changed the two double quotes in the 25 character example. Is something broken?

No. JavaScript escape rewrites exactly 9 of the 128 ASCII codes: backslash, double quote, single quote, newline, carriage return, tab, backspace, form feed and NUL. The ampersand and the angle brackets are perfectly legal inside a JavaScript string, so they pass through untouched and the output stays at 27 characters, two backslashes more than the input. The same input run through HTML escape instead reaches 45, because in that destination the ampersand and both brackets are the dangerous characters. The mode decides what counts as dangerous.

The URL escape mode encoded the slashes and the question mark in my full address. Was that wrong?

Nothing is wrong, but the mode is a component encoder, not a URL encoder. encodeURIComponent keeps 71 of the 96 printable ASCII characters and encodes everything else, including the slash, the colon, the question mark and the equals sign, so a full 53 character address with a query string comes out as the 75 character component https%3A%2F%2Futlkit.com%2Ftools%2Fstring-escape%2F%3Fq%3DTom%20%26%20Jerry. If you want the whole URL treated as one unit with its structure intact, the URL Encoder/Decoder tool makes that split explicit. In the other direction, decodeURIComponent throws on a dangling percent sequence such as %E0, and the tool shows the error instead of a half decoded string.

Does escape followed by unescape always give back the original string?

For input that was never escaped, yes. JavaScript escape then JavaScript unescape walks the same 128 code table forwards and back and returns the input unchanged, and the URL pair round trips too, hex pairs included. The failure comes from two other directions. One is double escaping: run HTML escape twice and the second pass escapes the ampersand inside the references the first pass wrote, so undoing takes two unescape passes, not one. The other is unescaping data that was never escaped: typing a percent sign followed by two digits that do not form a valid sequence, like a dangling %E0, makes decodeURIComponent throw, and the tool shows the error instead of a half decoded string.

Why does the 25 character example reach 45 after both the HTML escape and the URL escape?

Two different arithmetics, the same landing point. HTML escape adds 4 for the single ampersand, 5 for each of the two double quotes and 3 for each of the two angle brackets: 25 plus 20, 45. URL escape turns the four spaces, the ampersand, the colon, the two double quotes and the two angle brackets, ten single characters, into ten three character percent sequences, also 25 plus 20, also 45. The equality is a coincidence of this particular input, and the two 45 character outputs are different strings: one is full of ampersand references, the other of percent triples. Each destination counted its own dangerous characters, and both happened to charge the same total.

Related Articles