Encode and decode text, files and JSON as base64, base64url or hex, checked by decoding the result back
Initializing in your browser…
Percent-encode and decode against four character sets, build query strings, and take a URL apart
Decode a JSON Web Token and, given the secret or public key, actually verify its signature. Refuses alg: none and algorithm confusion
Exact conversion between any bases on BigInt, with fixed-width integer views, bitwise algebra and IEEE-754
You are decoding a value out of a log line and cannot tell whether it is text or binary.
Base64
//6AgQ==
Decoded
The bytes are not text. Those bytes are not valid UTF-8, so the text below is not what they contained. Re-encoding it will not give the original bytes back. As hex: fffe8081 (4 bytes)
A text decoder replaces anything that is not valid UTF-8 with U+FFFD and says nothing, so a tool that hands you the result as "the text" has quietly changed your data. This one checks first and says so, and offers hex output or a file download to get the bytes themselves. When encoding it goes the other way: it decodes its own output back and states on screen whether the result matches the input byte for byte.
Base64 maps arbitrary binary data into a 64-character alphabet of ASCII letters, digits, plus and slash, with equals as end padding. The purpose is transport through text-only channels: email bodies, JSON values, HTTP headers, URL parameters, and anywhere raw binary would be mangled by something expecting text. Every three input bytes become four output characters, which is why the output is always a multiple of four characters and about 133 percent the size of the input. The URL-safe variant (RFC 4648 section 5) replaces plus with hyphen and slash with underscore so the output can appear in URLs and filenames without escaping, because a plus is read as a space in a form-encoded query string and a slash breaks path parsing. JWTs use unpadded URL-safe base64. The two alphabets differ only in those two characters, so a string cannot be valid in both and mean different bytes: this tool works out which one it is reading and decodes it either way. The alphabet setting therefore only affects what it produces when encoding.
Base64 provides no security whatsoever. It is an encoding, not encryption: anyone can decode it with no key and no work. Putting sensitive data in base64 and calling it encoded for security is a textbook mistake that shows up repeatedly in breach postmortems. Use TLS in transit and real encryption at rest.
The tool converts as you type, in both directions, and checks its own work. When encoding, it decodes the result back and compares it to the input byte for byte, and says on screen whether that came out exactly right. When decoding it reports how much padding it had to add, and whether the string it was given was written in the standard or the URL-safe alphabet.
Decoding bytes as text is where a base64 tool can quietly change your data. TextDecoder replaces anything that is not valid UTF-8 with U+FFFD and says nothing about it, so a decoder that hands you the result as "the text" has silently altered the bytes: re-encoding what you see will not give the original back. This tool checks first, and when the bytes are not valid UTF-8 it says so, explains that the replacement characters are not what the bytes contained, and points you at the hex output or the file download to get the bytes themselves.
Invalid input is rejected with the reason rather than a generic failure. A character-class test alone is not enough: "A" and "AAA" contain only alphabet characters, but no base64 string has a length of 4n + 1, so a stray character is always an error and the tool names it. Padding in the middle of a string, more than two padding characters at the end, and characters outside the alphabet are each reported separately, with the offending characters listed.
Padding rules are a common source of bugs. Standard base64 pads with equals so the output is a multiple of four; a one-byte input gives XX==, two bytes gives XXX=, three bytes gives XXXX. RFC 4648 section 3.2 allows the padding to be omitted, which saves bytes but requires a decoder that can handle it. This tool accepts padded and unpadded input and lets you choose which to produce, and base64url output drops the padding by convention.
The 33 percent overhead makes base64 the wrong choice in some places. Embedding a 5 MB image as a data URI bloats the HTML by about 6.7 MB, and a browser cannot cache inline data, so every page load pays for it again. Under about 5 to 10 kB the saved HTTP request can be worth it; above that, keep the file separate. The same trade-off applies to binary in JSON.
Convert a small image to a data URI so it loads inline without an extra HTTP request, with the mime type taken from the file.
Encode a binary attachment as a base64 string to include in a JSON body, and confirm on screen that it decodes back to the same bytes.
Decode base64 from an API response or a log line. If it turns out to be binary rather than text, the tool says so instead of showing you mojibake.
Paste an unpadded URL-safe segment straight in. The alphabet and the missing padding are both worked out for you.
No. It is an encoding, not encryption. Anyone can reverse it without a key. It only makes binary safe to carry through channels that expect text.
Every three input bytes become four output characters, so the output is 4/3 the size, about 33 percent larger, plus padding and any line breaks.
A variant that uses hyphen instead of plus and underscore instead of slash so the string is safe in a URL or a filename, usually without padding. JWTs use it. This tool decodes either alphabet without being told which.
No. Unpadded input is accepted, and the tool reports how many padding characters it added.
Because the bytes are not valid UTF-8 text. Those are U+FFFD replacement characters, which is what a text decoder substitutes for bytes it cannot read, and they are not what the data contained. The tool warns when this happens. Switch the output to hex, or use File mode to download the bytes.
The tool decodes its own output back and compares it to the input byte for byte, and says so under the result. If that line ever said otherwise, the output would not be trustworthy.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.