Utilities
Encode text as Base64, URL percent-encoding, HTML entities, Unicode escapes, hexadecimal bytes or binary — one page with a type selector instead of six. UTF-8 is handled properly, so Bangla, accented letters and emoji encode correctly. Runs entirely in your browser; nothing is uploaded.
Up to 262,144 bytes, read as UTF-8 — emoji and any script work.
Type something, then press Encode.
UTF-8 bytes → Base64 (RFC 4648 standard alphabet, `=` padded, one line).
The text is encoded to UTF-8 first, so Bangla, accented letters and emoji produce correct Base64 instead of the errors a direct btoa() call gives.
Encoding happens locally in your browser. Your text is not uploaded, not stored and not sent anywhere, and nothing you type appears in the page address. Encoding is not encryption — it changes how text is written, not who can read it, and anyone can decode the output in one step.
Looking for something else? Browse all tools.
Encode text as Base64, URL, HTML entities, Unicode escapes, hexadecimal or binary — six encodings, all computed locally, with the format variants that actually differ in practice exposed as options rather than hidden.
Base64 turns arbitrary bytes into characters that survive text-only channels, mail bodies and JSON strings. URL encoding makes a value safe inside a query string. HTML entities stop text being read as markup. Unicode escapes represent characters that cannot be typed directly. Hex and binary are the raw byte representations, useful when you want to see exactly what the bytes are.
URL encoding has two forms, and only one of them is here: percent-encoding leaves a space as `%20`, while form encoding, which is what an HTML form submits, writes it as `+`. They are different schemes rather than two settings of one, so this tool does percent-encoding only. Unicode has the same split — `\uXXXX` escapes and `U+XXXX` code points look similar and mean different things to different systems. Only the notations that genuinely differ are exposed as options — the two above, plus spaced against continuous for hex and binary. A single "URL encode" button would be wrong half the time, so this tool states which scheme it applies: percent-encoding.
None of these hide anything. Base64 is reversible by anyone in one step, and it is used as an encoding, not a cipher — passing it off as encryption is one of the most common mistakes in this area. If a value needs to be secret, it has to be encrypted or stored somewhere private, not encoded.
The text is encoded in this page with plain JavaScript. Nothing is submitted, and there is no request to inspect — open the Network tab and encode, and it stays empty.
No, and treating it as if it were is a real security bug. Base64 is a reversible encoding with no key: anyone who recognises it can decode it instantly. It exists so that binary data can travel through text-only channels without being mangled, not to keep anything secret.
They differ in how a space is written: percent-encoding produces `%20`, and form encoding produces `+` — the latter being what a browser sends when an HTML form is submitted as `application/x-www-form-urlencoded`. They are different schemes, not two settings of the same one, so this tool does percent-encoding only, which is the right choice for a URL path or a query value. Pasting `+` where a system expects `%20` produces a value that looks nearly right and fails at the other end.
To display characters literally in a context that would otherwise interpret them. An ampersand, an angle bracket or a quote inside HTML has to be escaped or it changes the document's structure. The same applies when text is being placed into an attribute or a template, where an unescaped character can break the markup.
