Free encoder decoder

1. Pick a format. Choose HTML entities, hex, binary, ROT13, or Unicode escape from the format selector above the input.
2. Choose a direction. Switch between Encode and Decode. ROT13 is symmetric — the same operation both encodes and decodes, so there's just one “Apply” step.
3. Paste your text. Type or paste into the left pane, or use Upload .txt to load a file straight in.
4. Grab the result. The right pane updates live as you type. Use Copy to grab it, Download to save it as a .txt file, or Swap to flip the result back into the input and reverse the direction.

Because every conversion happens on your device using hand-rolled, UTF-8-safe logic, there's no upload limit, no waiting on a server, and no risk of sensitive text leaving your machine.

HTML entities are reserved text sequences — starting with & and ending with ; — that represent a character HTML would otherwise treat as markup. The five characters that matter most for security are &, <, >, ", and '. If you insert raw user input containing <script> into a page without escaping it, a browser will execute it — that's the root cause of most cross-site scripting (XSS) vulnerabilities. Escaping those characters to <, >, and friends turns dangerous markup into inert, displayable text.

Two encoding styles show up in the wild:

• Named entities — mnemonic names like & (ampersand), < (less-than),   (non-breaking space), and © (©). Easy to read, but the browser only recognizes a fixed, known set of names.
• Numeric character references — < (decimal) or < (hexadecimal) both represent <. Numeric references work for any Unicode code point, including emoji and symbols with no named entity, which is why this tool falls back to numeric form (😀 for 😀, for example) when encoding anything outside &/</>/"/'.

For example, encoding Tom & Jerry's <show> produces Tom & Jerry's <show>. Decoding reverses the process: this tool understands both named entities (a curated set covering the most common ones — amp, lt, gt, quot, apos, nbsp, copy, mdash, and more) and numeric references in either decimal or hex form.

It helps to know where entity encoding actually belongs, because it's often confused with other kinds of escaping. HTML entities are for text that ends up inside HTML markup — a paragraph, a heading, an attribute value. They are not a substitute for URL encoding (which escapes characters unsafe inside a URL) or for JavaScript string escaping (which uses backslashes, not ampersands). Mixing them up is a common source of double-encoding bugs, where text like < shows up on a page because the same string was HTML-escaped twice. A good rule of thumb: escape as close as possible to the point where the text is inserted into HTML, and escape exactly once. This tool doubles as a full HTML entity decoder for the reverse job, turning escaped markup back into plain, readable text.

The reverse direction matters just as much. Content pulled from an RSS feed, a CMS export, or an old database dump often arrives pre-escaped — you'll see literal & or ' sequences where you expected plain punctuation. Running that text through the decode side of this tool converts it back to normal, readable characters before you store it, search it, or re-render it somewhere that will escape it again on its own (like a modern React or Vue template, which escapes automatically).

Every piece of text is, underneath, just a sequence of bytes. Hex encoding shows each byte as two hexadecimal digits (00–FF), which is compact and exactly matches how bytes are usually written in debuggers, network dumps, and low-level documentation. Binary encoding goes one level further and shows each byte as eight 1s and 0s — the literal bit pattern a computer stores. Use the decode side as a quick hex to text converter when you have a raw byte dump and need to read the message hiding inside it, or as a binary translator when you're staring at a string of 1s and 0s and just want to know what it says.

Both conversions in this tool go through TextEncoder, so multi-byte UTF-8 characters (emoji, accented letters, non-Latin scripts) are handled correctly rather than mangled. For example, the letter A encodes to hex 41 and binary 01000001, while the euro sign € — a 3-byte UTF-8 character — encodes to hex e2 82 ac.

Decoding is tolerant of common formatting quirks: hex input can include spaces, colons, dashes, or 0x prefixes (so 48 65 6c 6c 6f, 48:65:6c:6c:6f, and 0x48 0x65 0x6c 0x6c 0x6f all decode the same way), and binary input can be space-separated 8-bit groups or one continuous run of bits. If the byte count is odd, a character isn't valid hex/binary, or the resulting bytes aren't valid UTF-8, the tool shows a plain-language error instead of silently producing garbage.

Hex shows up constantly outside of pure text conversion, too: color codes on the web (#FF5733) are hex, MAC addresses and hardware IDs are hex, and most memory dumps, packet captures, and file signatures (“magic bytes”) are described in hex because it maps cleanly onto bytes — one hex digit covers exactly 4 bits, so two digits cover a full byte with no rounding. Binary is used less often for everyday work, but it's the clearest way to see bit-level detail: flags packed into a single byte, checksum calculations, or simply building intuition for why a byte can only hold 256 distinct values (0–255, or 00000000 to 11111111).

A quick gut-check when decoding: a valid hex byte string always has an even number of hex digits (each byte is two digits), and a valid binary byte string is always a multiple of 8 bits. If you paste something with an odd digit count or a stray character outside 0–9/a–f (hex) or 0/1 (binary), that's the tool telling you the source data got truncated or corrupted somewhere upstream.

ROT13 (“rotate by 13”) is a substitution cipher that shifts every letter 13 places through the alphabet — A becomes N, B becomes O, and so on, wrapping back around at Z. Because the English alphabet has 26 letters and 13 is exactly half of that, applying ROT13 twice returns the original text — it's its own inverse, which is why this tool shows a single “Apply” action instead of separate encode/decode buttons.

ROT13 dates back to early Usenet newsgroups in the 1980s, where it was used to hide spoilers, puzzle solutions, and off-color jokes from casual glances without actually being secret — anyone could decode it in their head or with a one-line script. It provides zero cryptographic security, but it's still used today for exactly that original purpose: obscuring text just enough that you have to choose to read it. Numbers, punctuation, and whitespace pass through unchanged, and letter case is preserved (so Hello becomes Uryyb).

ROT13 is a special case of a Caesar cipher, one of the oldest known encryption techniques, reportedly used by Julius Caesar to shift military messages by three letters. Any fixed rotation from 1 to 25 works the same way, but 13 is special for the 26-letter Latin alphabet specifically because it's self-inverse — no other single rotation has that property. That's also why ROT13 shows up so often in old forum software and browser bookmarklets: a “decode” button doesn't need to exist, since the encode button already does both jobs.

A Unicode escape sequence represents a character by its code point instead of the literal glyph — useful when text needs to survive being embedded in source code, JSON, URLs, or any format that only safely supports ASCII. JavaScript and JSON both use the \uXXXX form, where XXXX is four hex digits: the letter é becomes \u00e9, and the smiley emoji 😀 — which sits outside the Basic Multilingual Plane — becomes a surrogate pair, 😀, because a single 16-bit escape can't address it directly.

Modern JavaScript (ES2015+) also supports the more compact \u{XXXXX} code-point form, which can represent any Unicode character — including ones above the BMP — in a single escape without needing a surrogate pair. Separately, older C-style languages and some URL/byte contexts use \xNN, a two-digit hex escape limited to the 0–255 range.

This tool's decoder understands all three forms — \uXXXX, \u{X..}, and \xNN — and its encoder produces standard \uXXXX escapes (with surrogate pairs where needed) so the output pastes cleanly into JavaScript strings or JSON values.

This is especially useful when debugging “invisible” text problems: two strings that look identical on screen but fail an equality check often differ by a single non-printing character, like a zero-width space (\u200b) or a curly quote that got typed instead of a straight one. Running suspicious text through the encoder makes every character explicit, which turns an invisible bug into something you can actually read and diff. It's also the standard way to safely hard-code non-ASCII strings — API response fixtures, internationalized labels, log messages — in codebases or CI configs that enforce ASCII-only source files.

Yes. Every conversion — HTML entities, hex, binary, ROT13, and Unicode escapes — runs entirely in your browser using hand-rolled, UTF-8-safe JavaScript. Nothing you type is sent to a server, logged, or stored, so it's safe to use with API keys, credentials, internal strings, or any other sensitive text. It also works offline once the page has loaded.

• Web developers escape user input to HTML entities before rendering it, closing off a common XSS attack vector.
• Backend and API engineers convert text to Unicode escapes to safely embed special characters in JSON payloads or JavaScript source.
• Security researchers inspect and decode hex or binary payloads while analyzing malformed input or protocol traffic.
• Students & educators use hex/binary views to teach how text is actually represented in computer memory.
• Puzzle and forum communities still use ROT13 to hide spoilers, answers, and off-color jokes the old-fashioned way.
• Support & QA teams decode garbled or escaped text from logs, tickets, and bug reports back into readable form.