An HTML escape job on around 50,000 characters of source stops being a quick paste-and-go task because output length grows, the browser pauses briefly, and the choice between encoding modes swings the result size by a measurable factor. The HTML Entity Encoder / Decoder processes up to 500,000 JavaScript characters in the browser, and every code point above ASCII 126 can either pass through as readable text or turn into an uppercase hexadecimal numeric reference, and non-ASCII mode can make output substantially longer than the source for documents that contain accents, CJK glyphs, or emoji. That single scaling fact, where output length balloons when you switch to the non-ASCII option, is what most separates a small escape job from a large one, and it is the reason mode choice matters before you paste. It is also why running a small representative sample first is the single most useful habit when the input is long: it surfaces unexpected content and confirms the downstream expectations before the source multiplies across half a million characters.
What Changes at Scale for HTML Escaping
Three things behave differently once a paste crosses from a few hundred words into a small document. First, output length stops being roughly equal to input length the moment non-ASCII mode is selected, because every accented character, CJK glyph, or emoji expands from one character to a multi-character reference. Second, decode mode puts a fuller load on the browser's HTML parser, since it delegates to the WHATWG named character reference table rather than a small fixed map, and very large pastes with many references will pause the UI briefly while the parser walks the table. Third, the practical cost of a wrong mode choice grows with the size of the paste, because re-encoding a 300,000-character block is a noticeably heavier task than re-encoding a paragraph. Knowing those three pressures up front is what makes large-text encoding feel controlled rather than accidental.
Choosing Between Basic and Non-ASCII Mode
Two encoding modes behave very differently once the source stops being a paragraph, and the table below summarises the practical difference for a long paste.
| Aspect | Basic encoding | Non-ASCII encoding |
|---|---|---|
| Characters escaped | & < > " ' | Same five syntax characters, plus every code point above ASCII 126 |
| Output length for ASCII-only text | Same as input, slightly longer where quotes appear | Same as input, slightly longer where quotes appear |
| Output length for text with accents or emoji | Same as input | Each non-ASCII character becomes a multi-character hexadecimal reference, so length grows substantially |
| Readability of result | High; ordinary words stay readable | Low outside the ASCII range |
| Recommended when | You want a clean, readable escape for an HTML text node or attribute | A legacy workflow, transport, or teaching example specifically requires numeric references |
MDN's character reference glossary recommends avoiding unnecessary references because modern UTF-8 HTML can carry Unicode directly, which is the same reasoning the basic mode applies to every character outside the reserved set. Reach for non-ASCII mode only when an external system or legacy pipeline specifically asks for numeric references, or when you are constructing a comparison or teaching example where the reference form itself is the point. For a typical 200,000-character article with light accent usage, basic mode keeps the file close to its original size; non-ASCII mode on the same article will land well above the source length and should be measured on a small sample before committing to it for repeated use.
How to Encode a Large Block of Text
- Open the HTML Entity Encoder / Decoder and pick the Encode direction. Choose Basic for readable output that keeps ordinary ASCII text intact, and choose Non-ASCII only when the downstream system or transport specifically requires numeric references for code points above ASCII 126.
- Paste a small representative sample first — a paragraph or two that includes any accent, emoji, or quoted HTML attribute content you expect in the full block — and run the conversion. This is the cheapest moment to confirm the mode choice.
- Inspect the result for the five reserved characters: ampersand should appear only as &, less-than as <, greater-than as >, double quote as ", and apostrophe as '. Confirm that ordinary words, numbers, spaces, tabs, and line breaks still read normally.
- If non-ASCII mode is in use, spot-check one accented character or emoji and confirm the reference is uppercase hexadecimal, such as É for É or 😀 for 😀, rather than a pair of broken surrogate references. The encoder iterates Unicode code points rather than UTF-16 code units, so a supplementary-plane emoji should appear as a single reference.
- Paste the full large block into the input area, run the conversion again, and copy the result only after the receiving context — an HTML text node, an attribute value, a code sample, or a documentation page — has been confirmed. If the block approaches the input bound, split at safe boundaries rather than truncating.
Working Inside the 500,000-Character Limit
The encoder bounds input at 500,000 JavaScript characters to keep work local and responsive, which is generous for most documents but tight for very long manuscripts, concatenated log files, or pasted multi-file exports. The practical workflow is to split the source at safe boundaries — end of paragraph, end of a JSON object, end of a code block, end of an HTML element — rather than mid-string, encode each chunk with the same mode, and concatenate the results before pasting them into the target HTML. Running the conversion on a tiny sample first does two things at once: it confirms that the encoding mode produces the references the downstream system expects, and it surfaces any unusual content — control characters, stray null bytes, malformed ampersands in the source, or unexpected non-ASCII strings — before that content multiplies across half a million characters. The page does not save history, does not fetch a remote reference table, and does not transmit input, so each chunk you encode stays in the browser only and disappears when you close the tab.
Why Decoded Output Needs Special Care
Decode mode is broader than the small encode table because it asks the browser's HTML parser to apply the full WHATWG named character reference table, including legacy aliases and references that resolve to more than one code point, so almost any reference sequence you throw at it comes back as readable text. That same breadth is also a safety boundary at scale: a reference sequence such as <script>alert(1)</script> decodes to the literal characters <script>alert(1)</script>, and although the tool never executes that string inside itself, copying it into an unsafe innerHTML sink turns it back into live markup that runs in the page. Treat every decoded value as untrusted data and apply context-aware escaping at the actual output boundary rather than trusting the decoder to have neutralised anything along the way. The decoded result is placed in a plain read-only text area so it cannot run inside the tool itself, but the moment it leaves the page it is your responsibility again, and the larger the paste the easier it is to lose track of one stray sequence that needs handling.
When HTML Escaping Is Not Enough
HTML syntax escaping is not the same as safely constructing a URL parameter, a JavaScript string literal, a CSS value, a SQL query, or an HTTP header, and at large scale the cost of mixing those contexts up multiplies with the size of the paste. A URL needs percent-encoding handled by a URL encoder; a JavaScript string needs its own quote and backslash handling; a CSS value lives inside a different parser again; XML has a much smaller predefined entity set than HTML and parses references differently, so a reference that resolves in HTML can fail in XML. The tool does not replace framework auto-escaping, a trusted templating engine, a sanitizer, or a Content Security Policy, and it is not a substitute for those controls simply because the input is large. Use the encoder for the specific job of preparing text for an HTML text node or attribute, hand off the result to the appropriate context-aware layer at the final output boundary, and pick a dedicated tool — such as the URL Decoder for percent-encoding or the UTF-8 Encoder / Decoder for byte-level work — when the target format is not HTML. The WHATWG HTML Living Standard named character references list is the underlying table the decoder uses, and MDN's character reference glossary explains when references are and are not necessary in modern UTF-8 HTML.
For a deeper look, see ROT13 Decoder Example: What Changes and What Stays.
For a deeper look, see Binary to Text on Mac Without Using Terminal.