Encoder / Decoder
Encode and decode Base64, URLs and HTML entities, and convert number bases.
Related tools
- URL & UTMSplit a URL into its parts and build campaign links with UTM parameters.
- Hash GeneratorHash text or a file with MD5, SHA-1, SHA-2, SHA-3 or HMAC.
- JWT DecoderDecode JWT header and claims, warn about the algorithm and header tricks that get tokens forged, sign new tokens, and verify HS, RS, PS and ES signatures in your browser.
- JSON ToolsFormat, minify, repair and validate JSON with exact error positions, browse it as a tree, and convert between JSON, CSV and YAML.
About this tool
Encoder / Decoder is four converters behind one mode switch: Base64, percent-encoding, HTML entities and number bases. Base64 encodes the UTF-8 bytes of your text and can write the URL-safe alphabet of RFC 4648 section 5 (- and _, padding dropped), while the decoder accepts either alphabet; percent-encoding calls the browser's encodeURIComponent or encodeURI, which implement the unreserved and reserved sets of RFC 3986; the entity mode escapes the five characters that matter in markup - ampersand, less-than, greater-than, double quote and apostrophe - and can additionally write every non-ASCII character as a numeric reference; the base converter uses BigInt, so a value of any size converts between bases 2, 8, 10, 16 and 36 without rounding. It converts, it does not protect - Base64 is an encoding and not encryption, and escaping entities here is not a replacement for escaping in the template that builds your page. It works on text you paste: there is no file upload, and it does not hash, sign or decode JWTs.
Every mode is arithmetic and string work done in your browser: TextEncoder and TextDecoder for UTF-8, btoa and atob for Base64, the browser's own encodeURIComponent, encodeURI and decodeURIComponent for percent-encoding, and BigInt for the base converter. Nothing you paste is sent to the XGM API, written into the URL or saved in this browser - the address keeps only the mode, as ?mode=url, ?mode=html or ?mode=base, with Base64 as the default that carries no parameter. The output updates as you type, and copy, download and JSON export are produced from what is already on screen. The only request this page makes by itself is the page-view event sent after you accept analytics, which records the path and the tool name and never your input. The character set chosen for Base64 decoding is handed straight to the browser's own TextDecoder, so ISO-8859 and Windows-1252 payloads are decoded in the page as well, and the file offered when the result is binary is built from the byte array already on screen.
How to use it
- Open the Encoder / Decoder tool.
- Paste or type the input you want to inspect.
- Read the result, which is computed in your browser; the input is not sent to XGM.
- Copy the output only after checking it looks correct.
- Use related XGM tools if you need a broader diagnostic view.
FAQ
Why did my Base64 decode into a hex dump instead of text?
The input decoded to bytes, but those bytes are not valid UTF-8, so there is no text to show. That is what you get when the payload is an image, a compressed blob, UTF-16 text or a truncated string: the result reports the byte count and prints the first 256 bytes in hex. Decoding is strict on purpose - silently replacing invalid sequences with U+FFFD would hide the fact that the data is not text.
Can I decode Base64url, or Base64 that has lost its padding?
Yes. Whitespace and line breaks are stripped, - and _ are mapped back to + and /, and missing = padding is restored before decoding, so the standard alphabet of RFC 4648 section 4 and the URL-safe one of section 5 both work in the same box. The only length that is rejected is one character past a multiple of four, which no valid Base64 string can have. On the encode side the URL-safe option writes - and _ and leaves the padding off, which is what JWTs and URL parameters expect.
Should I use encodeURIComponent or encodeURI?
Use the component option for one piece of a URL - a query value, a path segment - because it also escapes the RFC 3986 reserved characters : / ? # & = that would otherwise end your value early. Use the whole-URL option only on an address that is already assembled, since it deliberately leaves those characters intact. Encoding a value with the whole-URL option is the classic bug: an & inside it silently splits one parameter into two. Decoding uses decodeURIComponent for both.
Why does decoding turn + into a space?
Because the “Treat + as a space” option is on, and it replaces + before decoding. Percent-encoding itself has no such rule - + means a literal plus in RFC 3986 - the convention comes from the application/x-www-form-urlencoded serialisation used by HTML forms and query strings. Turn the option off when you are decoding a path, a Base64 payload or anything where a plus is real data. A % that is not followed by two hex digits, or an escape that is not valid UTF-8, is reported with the offending fragment.
Which HTML entities does the decoder actually know?
Every numeric reference, decimal (é) and hexadecimal (é) alike, plus about thirty common named ones: amp, lt, gt, quot, apos, nbsp, copy, reg, trade, the dashes and quotation marks, and the currency and typographic signs. Any other named entity is left in the text exactly as you pasted it and counted in the note under the result, so an unresolved name is visible rather than lost. Encoding goes the other way with the five characters that matter in markup, writing ' as the numeric ', and the optional non-ASCII pass turns every remaining character into a decimal reference.