Media tools are next. Everything ships the same way: it runs in your tab, or it does not ship.
Encoders & Decoders
Base64 in every flavour, Base32, percent encoding and HTML entities, both directions, with the edge cases handled: UTF-8 text, URL-safe alphabets, whole files and images as data URIs, double-encoded strings and binary payloads. Everything is decoded in your browser, which matters when the string you are debugging is a token.
11 tools. All in your browser.
Nothing you paste is uploaded, and once a tool has loaded it keeps working offline. Free, no signup.
Base64
5 tools
For binary that has to travel through a text channel: an image in a CSS data URI, a file in a JSON field, an attachment in an email. The text encoder handles UTF-8 correctly, so an emoji does not crash it the way btoa does; the file and image converters read dropped files byte for byte and hand back data URIs with ready-to-paste CSS and HTML snippets. The decoder repairs missing padding and shows binary payloads as a hex dump you can download, and the Base64URL page speaks the URL-safe alphabet JWTs are made of, in both directions.
The encoding humans can retype: case-insensitive, and the alphabet skips 0, 1, 8 and 9 so nothing gets misread off a screen. Its one mainstream job is the 2FA setup key, which is why the decoder here accepts keys exactly as enrollment pages show them, lowercase, grouped in fours and without padding, and names the exact character when one was mistyped. base32hex is a flag away.
Encoding a single parameter value and encoding a whole URL are different jobs, and mixing them up is how redirect parameters break. Both modes sit side by side here, plus form encoding where a space becomes a plus sign. The decoder has a repeat option that peels off double encoding, so the %2520 you found in a log unwraps in one step.
A JSON Web Token is three Base64URL segments with dots between them, which is exactly why a plain Base64 decoder chokes on it. This one splits the token, pretty-prints the header and the payload, explains the seven registered claims and turns exp, iat and nbf into real dates. What it will not do is ask for your signing secret, because a page that wants your key to tick a green box is a page to walk away from.
Escaping the five characters that decide whether your output is safe is a different job from converting every umlaut, so the two are separate switches rather than one setting. The decoder uses the full HTML5 table and always shows the result as text, never rendered, which is the part cheaper tools get wrong.
The parsers ship with the page, so a tool keeps working after you go offline.
Instant, as you type
Every tool runs the moment you type. No run button, no waiting, nothing to install.
Free forever, no signup
No account, no paywall, no trial that expires. All 70+ tools, free for everyone.
Encoding is not encryption
Base64 hides nothing. It maps three bytes onto four printable characters so binary data survives a channel built for text, and anyone can reverse it in one line. The same goes for percent encoding and HTML entities. If a value has to stay secret, it needs a key.
Which is why none of this is uploaded
The strings people decode are session cookies, bearer tokens, signed URLs and password reset links. Pasting one of those into a server-side decoder means handing over a live credential to whoever runs it. Everything here runs in your tab, and it keeps working after you disconnect.
Choosing and debugging an encoding
What is the difference between encoding, encryption and hashing?
Encoding changes the representation and is reversible by anyone: base64, percent encoding, HTML entities. Encryption changes the representation and is reversible only with a key. Hashing is deliberately one-way and produces a fixed-size digest that cannot be turned back into the input at all. The three answer different questions (can it travel, can others read it, has it changed), and the common security mistake is reaching for the first when the requirement was the second.
When do I need URL encoding and when do I need HTML escaping?
Percent encoding is for putting a value into a URL, HTML escaping is for putting a value into a document. They protect against different things and are not interchangeable: a value that is percent-encoded but not escaped still closes an attribute and injects markup, and a value that is escaped but not percent-encoded still breaks a query string at the first ampersand. When a URL is written into an href, both apply, in that order: encode the value for the URL, then escape the finished URL for the attribute.
How much bigger does encoded data get?
Base64 adds a third, exactly 4 output characters per 3 input bytes plus padding. Base32 is worse at 8 characters per 5 bytes, which is 60 percent, and it exists for case-insensitive, human-transcribable strings, not for size. Percent encoding varies with the content: pure ASCII letters cost nothing, while arbitrary binary costs three characters per byte, so it is the wrong choice for anything larger than a few hundred bytes.
Which encoding should I use for binary data inside JSON?
Base64 in a string field, because JSON has no byte type and a raw byte sequence is not valid UTF-8. Use the standard alphabet when the value stays inside the body and base64url when the same value might later travel in a URL or a filename, so nothing has to be re-encoded on the way. For anything more than a few hundred kilobytes, put the bytes somewhere else and send a reference: the 33 percent overhead is paid on every hop, and it defeats streaming.
Why does my encoded string break in an email or a URL?
Almost always because the standard base64 alphabet meets a context where its characters mean something. A plus sign in a query string decodes back as a space, a slash starts a new path segment, and equals signs are reserved separators, so a token pasted into a URL arrives corrupted with no error anywhere. In email the culprit is line wrapping instead: MIME breaks base64 at 76 characters, and a decoder that does not strip the newlines rejects the payload.