encode text or files to Base64, or decode Base64 back to text and files. runs entirely in your browser.
encoded output will appear here
Encode any text or file into Base64, or paste a Base64 string and decode it back. Bidirectional, instant, and entirely client-side — your input never reaches a server.
Base64 is an encoding, not encryption. It is a way of representing arbitrary binary data using only 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /, plus =for padding. The encoding is reversible by anyone — there is no key, there is no secret. If you Base64 something to “hide” it, you have not hidden it.
The reason it exists is that for most of computing history, the safe channels for moving data were text-only. Email, URL query strings, JSON values, XML attributes, log files — all of these handle text but choke on raw binary. Base64 buys you a translation: any 3 bytes of binary become 4 ASCII characters that survive every text-handling step in any pipeline.
Every 3 bytes of input become 4 characters of output. That is a 33% size increase, which is the cost of buying ASCII safety. For a 10MB binary file, the Base64 representation is ~13.3MB. This matters when:
data: URIs. A 100KB image becomes a 133KB inline blob. Tolerable for icons and small assets; painful for hero images.multipart/form-data, presigned URLs) avoid this.For inputs whose length is not a multiple of 3, Base64 pads with = at the end so the output length is always a multiple of 4. The padding is purely structural — the decoded value does not include the padding characters.
Standard Base64 uses + and /, which both have meaning in URLs. That makes a Base64 string unsafe to drop directly into a URL path or query parameter without further encoding. URL-safe Base64 substitutes - for + and _ for /, leaving the rest of the alphabet untouched. Many systems also drop the trailing = padding entirely.
JWT tokens use URL-safe Base64 without padding. Many modern APIs do too. If you are decoding a string that looks Base64-shaped but contains - or _, that is what you are looking at, and any decent decoder (this one included) handles both flavors automatically.
Whitespace and line wrapping
UTF-8 vs binary inputs. Encoding the string "hello" means encoding the bytes of its UTF-8 representation, which for ASCII characters is the same as the characters themselves. For non-ASCII text (emoji, accented characters, non-Latin scripts), the underlying bytes are multi-byte UTF-8 sequences, and the Base64 output reflects that. A common confused-about-encoding situation: encoding “café” in UTF-8 yields a different result than encoding it in Latin-1, because the é is two bytes in UTF-8 and one byte in Latin-1.
Decoding looks like garbage. Usually one of three causes: (1) the input was not actually Base64 — it was URL-encoded percent-escapes, (2) the Base64 was a binary blob you are trying to render as text but it was never text to begin with, or (3) character-set mismatch between encoder and decoder.
Base64 encoding is one of those operations that has zero good reason to involve a server. The transformation is purely local, fast, and benefits from notsending your input — which might be an API key, a password hash, or a confidential payload — to a third party. This implementation uses the browser's native btoa / atob functions for short strings, and a chunked variant for files larger than browser memory will tolerate in a single call.
Encode any text or file into Base64, or paste a Base64 string and decode it back. Bidirectional, instant, and entirely client-side — your input never reaches a server.
Base64 is an encoding, not encryption. It is a way of representing arbitrary binary data using only 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /, plus =for padding. The encoding is reversible by anyone — there is no key, there is no secret. If you Base64 something to “hide” it, you have not hidden it.
The reason it exists is that for most of computing history, the safe channels for moving data were text-only. Email, URL query strings, JSON values, XML attributes, log files — all of these handle text but choke on raw binary. Base64 buys you a translation: any 3 bytes of binary become 4 ASCII characters that survive every text-handling step in any pipeline.
Every 3 bytes of input become 4 characters of output. That is a 33% size increase, which is the cost of buying ASCII safety. For a 10MB binary file, the Base64 representation is ~13.3MB. This matters when:
data: URIs. A 100KB image becomes a 133KB inline blob. Tolerable for icons and small assets; painful for hero images.multipart/form-data, presigned URLs) avoid this.For inputs whose length is not a multiple of 3, Base64 pads with = at the end so the output length is always a multiple of 4. The padding is purely structural — the decoded value does not include the padding characters.
Standard Base64 uses + and /, which both have meaning in URLs. That makes a Base64 string unsafe to drop directly into a URL path or query parameter without further encoding. URL-safe Base64 substitutes - for + and _ for /, leaving the rest of the alphabet untouched. Many systems also drop the trailing = padding entirely.
JWT tokens use URL-safe Base64 without padding. Many modern APIs do too. If you are decoding a string that looks Base64-shaped but contains - or _, that is what you are looking at, and any decent decoder (this one included) handles both flavors automatically.
Whitespace and line wrapping
UTF-8 vs binary inputs. Encoding the string "hello" means encoding the bytes of its UTF-8 representation, which for ASCII characters is the same as the characters themselves. For non-ASCII text (emoji, accented characters, non-Latin scripts), the underlying bytes are multi-byte UTF-8 sequences, and the Base64 output reflects that. A common confused-about-encoding situation: encoding “café” in UTF-8 yields a different result than encoding it in Latin-1, because the é is two bytes in UTF-8 and one byte in Latin-1.
Decoding looks like garbage. Usually one of three causes: (1) the input was not actually Base64 — it was URL-encoded percent-escapes, (2) the Base64 was a binary blob you are trying to render as text but it was never text to begin with, or (3) character-set mismatch between encoder and decoder.
Base64 encoding is one of those operations that has zero good reason to involve a server. The transformation is purely local, fast, and benefits from notsending your input — which might be an API key, a password hash, or a confidential payload — to a third party. This implementation uses the browser's native btoa / atob functions for short strings, and a chunked variant for files larger than browser memory will tolerate in a single call.
PDF utilities, image tools, developer helpers — all free, no signup.
Build CSS box shadows visually with live preview.
Generate a robots.
Generate placeholder images with custom dimensions, colors, and text.
Drop a screenshot and frame it in a device mockup — iPhone, MacBook, iPad, Browser, or Android.
Convert text to binary, hexadecimal, and decimal byte values in real time.
See your public IP address, location, ISP, and timezone instantly.