Embedding user content in HTML without escaping it is one of the most common ways a site gets popped. The ChrysoKit HTML Entity Encoder gives you safe, paste-ready output in either direction.
Why use it
Manual entity escaping is painful and easy to get wrong. A dedicated tool makes the round-trip obvious and mistake-free.
How to use the HTML Entity Encoder
- Pick encode or decode.
- Paste your text or HTML.
- Choose between named, numeric or hex entities.
- Copy the safe output and paste it where it belongs.
Features worth knowing
Named, numeric, hex
Output entities as &, & or & depending on what your toolchain expects.
Round-trip safe
Encode then decode and the original text is preserved exactly.
Selective encoding
Optionally encode only the unsafe characters and leave the rest readable.
Pro tips
- Inside HTML attributes, encode quotes too. Otherwise an attacker can break out of the attribute.
- Named entities (&) are the most readable, but numeric entities work in every context.
- Encoding is not a substitute for templating frameworks that escape output by default. Use both.
Privacy first. The HTML Entity Encoder runs entirely in your browser. Nothing you enter is sent to a server.
When in doubt, encode. The HTML Entity Encoder is the one-step tool that makes 'safe by default' easy.
Open the tool: HTML Entity Encoder →
The day user comments started eating the page
A community site's comment section worked beautifully for months until a user wrote a comment explaining HTML itself, including a literal <table> tag. The browser, receiving the raw text, did what browsers do: opened a table in the middle of the comment thread, swallowing every subsequent comment into an invisible layout limbo. The next week someone posted a snippet containing <script>, and the matter graduated from cosmetic to security incident.
The fix was one line at the rendering layer... encode user text before output... but the post-mortem taught the durable lessons. Escaping belongs at output time, not input time: the database should store what the user wrote, and the encoding applied should match where the text lands, because HTML body context, attribute context and JavaScript context each have different rules. Encoding at input, the tempting shortcut, corrupts the stored data and still misses contexts added later.
The other lesson was the test suite that followed: every text-rendering surface now gets fed a canary string containing all five critical characters plus a fake script tag, and the test asserts they appear as visible text. It has since caught two regressions... both introduced by new features whose authors assumed someone else's layer was escaping. Nobody's layer escapes by assumption; that is rather the point.