Convert text to Base64 and decode Base64 back to text.
Base64 rewrites arbitrary binary data using only 64 printable ASCII characters, so it can pass safely through systems that were designed for text. It is an encoding, not encryption — anyone can decode it, and it provides no confidentiality whatsoever.
The alphabet is A-Z, a-z, 0-9, plus + and /, with = used for padding. Encoding takes three bytes (24 bits) at a time and splits them into four 6-bit groups, each mapping to one character.
Encoding the three characters Man:
When the input length is not a multiple of three, the final group is padded with =. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus a single =. This is why you so often see Base64 strings ending in equals signs, and why a string's length is always a multiple of four.
data:image/png;base64,..., avoiding an extra HTTP request.Authorization header carries username:password Base64-encoded. This is emphatically not security; without HTTPS it is plaintext for practical purposes.Standard Base64 uses + and /, both of which have special meaning in URLs and would need percent-encoding. The Base64url variant substitutes - for + and _ for /, and usually drops the padding. It is what JWTs and most URL-embedded tokens use. If a decode fails on a token from a URL, converting - and _ back to + and / is the first thing to try.
This bears repeating because the mistake is common and consequential. Base64 has no key. Anyone with the string can recover the original in seconds, which is exactly what this page does. Encoding a password, an API key or personal data does not protect it in any way — it merely makes it non-obvious to a casual reader, which is worse than useless because it can create a false sense of security.
For confidentiality you need actual encryption such as AES, with proper key management. For integrity you need a signature or MAC. For password storage you need a slow one-way hash such as bcrypt, scrypt or Argon2 — never an encoding, and never a fast hash.
Base64 inflates data by about 33%, plus padding. A 100 KB image becomes roughly 133 KB. That matters for data URIs: inlining a small icon saves a request and is often a net win, but inlining a large photograph adds a third to its transfer size and, because it sits inside the HTML or CSS, it cannot be cached separately or loaded lazily. The usual guidance is to inline below a few kilobytes and link anything larger.
This tool encodes and decodes locally in JavaScript using the browser's own btoa and atob functions with UTF-8 handling around them. Nothing you paste is transmitted or logged, which matters given how often Base64 strings contain credentials or tokens. You can confirm it in the Network tab of your browser's developer tools.
No. It is a reversible encoding with no key, and anyone can decode it instantly. It offers zero confidentiality. Use real encryption for secrets and a slow one-way hash such as Argon2 or bcrypt for passwords.
Padding. Base64 processes three bytes at a time into four characters, so when the input length is not a multiple of three the last group is padded — one leftover byte gives == and two give a single =. The result is always a multiple of four characters.
It is probably Base64url, which replaces + with - and / with _ and often omits padding. Swap those characters back and add = until the length is a multiple of four.
About 33% before padding. Three bytes become four characters. A 300 KB file encodes to roughly 400 KB, which is why inlining large images as data URIs is usually a poor trade.
Yes. The text is converted to UTF-8 bytes before encoding, so non-Latin scripts and emoji round-trip correctly. Naive implementations that call btoa directly on a Unicode string throw an error on any character above U+00FF.