HTML Encoder and Decoder
Convert markup characters such as angle brackets, ampersands, quotes, and apostrophes into HTML entities, or decode those entities back into readable text. This is useful when preparing code examples, inspecting escaped API output, building fixture data, or checking why a browser displays markup instead of showing it literally. The transformation happens locally and leaves the decision about sanitizing or rendering untrusted HTML to the application that will consume it.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Encode five common HTML-sensitive characters
- Decode named and numeric HTML entities through the browser parser
- Swap direction without copying by hand
- Preserve whitespace and line breaks in textareas
- Run locally with no uploaded source code
How to use HTML Encoder and Decoder
- 1
Choose encode or decode
Encode turns markup into displayable text. Decode turns entity sequences back into their character form for inspection or testing.
- 2
Paste the snippet
Add an HTML fragment, a log value, a code example, or an entity string. The result updates as you type.
- 3
Inspect the output
Check that ampersands, quotes, and angle brackets have the representation your target context expects before copying the result.
- 4
Copy the transformed text
Copy the result into documentation, a test fixture, a template, or the next stage of your development workflow.
How it works
Encoding uses a small explicit map for the five characters that most often become markup: ampersand, angle brackets, double quotes, and apostrophes. The input is not parsed as HTML before encoding, so whitespace, line breaks, and code-like text survive exactly. That makes the output useful in documentation and fixtures rather than only for a single rendered page.
Decoding passes the entity string to the browser's DOMParser in HTML mode and reads the resulting text content. That lets the platform handle named and numeric references without maintaining a second incomplete entity database. It also means the decoded output is text, not a live DOM fragment. The component renders it in a textarea, which is an intentional safety boundary.
Context still matters
HTML escaping is context-sensitive in real applications. Text placed between tags, an attribute value, a JavaScript string, a CSS value, and a URL each have different dangerous characters and encoding rules. This utility is excellent for inspecting and preparing simple HTML text, but a production framework's escaping primitive should be used at the point where untrusted data enters a document.
Do not decode user input and inject it with innerHTML because it looks readable. If the requirement is to show markup as code, keep it encoded. If the requirement is to allow a small safe subset of formatting, use a reviewed sanitizer with an allowlist and tests.
Five characters, and why not more
Plenty of encoders convert every non-ASCII character to a numeric entity, so café becomes café. This one does not, and the restraint is deliberate.
Entity-encoding accented characters was a workaround for a era when a document's character encoding was unreliable. With UTF-8 — which is what essentially every page and API now declares — é is simply a character, and encoding it produces output that is longer, harder to read, and harder to diff. A translator handed é sees markup where there was a word.
The five that are converted are the five that change meaning: & because it starts every other entity, < and > because they open and close tags, and both quote characters because they terminate attribute values. Those are the ones where leaving the character alone lets content become structure, which is the whole problem escaping exists to solve.
The case where this restraint bites is a document that is not UTF-8. If you are pasting into a legacy system that declares Latin-1 or leaves the encoding unstated, non-ASCII characters can arrive mangled, and there the heavier encoder is the right tool. Check what the destination declares before assuming it.
Attribute values are where escaping usually fails
Both quote characters are escaped here, and that is what makes the output safe to drop into an attribute — but only if the attribute is quoted.
Unquoted attribute values are legal HTML, and they end at the first whitespace character. <div class=$value> with a value of a onmouseover=alert(1) becomes two attributes, and no amount of quote-escaping prevents it because no quotes were involved. Escaping cannot save an unquoted attribute; only quoting it can.
The related trap is the URL attribute. href and src are parsed as URLs after entity-decoding, so a value of javascript:alert(1) is dangerous while being entirely free of characters this tool would touch — it contains nothing to escape. HTML escaping is the wrong control there; the right one is checking the scheme against an allowlist before the value ever reaches the attribute.
This is the general shape of it. Escaping answers "could this text become markup", and it answers that well. It does not answer "is this value acceptable here", and treating an escaped string as a safe string is how injection survives a code review.
Examples
Show a tag as code
The browser will display the encoded value as literal text instead of interpreting the button as markup when the result is inserted into an HTML text context.
Read an escaped API value
Decoding is useful while inspecting serialized content. The result is text again; it should only become markup if the consuming application deliberately renders it.
Frequently asked questions
Is HTML encoding the same as HTML sanitization?
No. Encoding changes special characters so a browser treats them as text, which is often the safest way to display untrusted input. Sanitization decides which markup, attributes, and URLs are allowed when you actually intend to render HTML. A decoder reverses entities and should not be used as a security filter before rendering user content.
Which characters does the encoder escape?
The tool escapes ampersand, less-than, greater-than, double quote, and apostrophe into common entity forms. Ampersand is handled first conceptually so existing entity-like text does not gain ambiguous meaning. HTML contexts can have additional rules, so attribute-specific escaping and a trusted framework are still the correct production boundary.
Can it decode every HTML entity?
Decoding uses the browser's HTML parser, which understands standard named and numeric entities supported by that engine. A string that resembles an entity but is malformed may remain text. That is preferable to a custom table that silently maps a typo to the wrong character or loses the original source.
Is my code sent to a server?
No. Encoding uses a local character map and decoding uses a DOMParser created in the page. The input stays in the browser tab and is not posted to an API. You can disconnect the network after loading the page and still transform snippets, logs, and fixture strings.