We use cookies and similar technologies to enhance your browsing experience, analyze site traffic, and personalize content and ads. By clicking "Accept", you consent to our use of cookies. Learn more in our Privacy Policy.
by Cosmovex
Encode text to Base64, decode Base64 strings to text, encode files to Base64. Supports standard and URL-safe Base64. No signup required.
Base64 is a way to represent arbitrary binary data using only 64 printable ASCII characters (A-Z, a-z, 0-9, plus + and /, with = for padding). It exists because many systems were built to move text safely but mangle raw bytes: email bodies, URLs, JSON fields, and HTTP headers can all corrupt or misinterpret control characters and high bytes. Encoding to Base64 turns any input into text those channels will pass through untouched.
This tool encodes text or files to Base64 and decodes Base64 back to its original form, directly in your browser. It handles full UTF-8 correctly (including emoji and non-Latin scripts), builds and parses data URLs for embedding images and fonts, and supports both standard and URL-safe alphabets. Everything runs locally in the page, so the data you paste or the files you drop never leave your device. That matters when the input is a config file, an API token, or anything you would not want sitting on someone else's server.
Base64 reads the input as a stream of bytes and regroups it. It takes 3 bytes (24 bits) at a time and splits them into four 6-bit chunks. Each 6-bit value (0-63) maps to one character in the alphabet. Because 3 input bytes always become 4 output characters, Base64 output is about 33% larger than the original.
When the input length is not a multiple of 3, the last group is padded with = so the output length stays a multiple of 4:
===Decoding reverses this exactly: it ignores padding, maps each character back to 6 bits, and reassembles the original bytes. The transform is lossless and fully reversible, so decoding valid Base64 always returns the exact original bytes.
Take the three-character string Man. Its ASCII byte values are 77 97 110, which in binary is:
01001101 01100001 01101110
Regroup those 24 bits into four 6-bit chunks:
010011 010110 000101 101110
19 22 5 46
Look each value up in the alphabet (A=0 ... Z=25, a=26 ... z=51, 0=52 ... 9=61, +=62, /=63):
19 → T 22 → W 5 → F 46 → u
So Man encodes to TWFu with no padding. Now try just M: one byte is 8 bits, which fills one 6-bit chunk plus 2 spare bits, so you get TQ followed by ==. That single character is why M becomes TQ==.
Base64 shows up anywhere binary data has to ride inside a text-only channel:
data:image/png;base64,... so it loads without a separate request.Authorization: Basic header is base64(username:password). Decoding such a header reveals the credentials in seconds, which is exactly why Basic Auth needs HTTPS.A key point: Base64 is encoding, not encryption. It hides nothing. Anyone can decode it instantly, so never treat it as a way to protect sensitive data.
The standard alphabet uses + and /, but both of those have special meaning in URLs and filenames: + can be read as a space in query strings, and / is a path separator. To make Base64 safe in those contexts, the URL-safe variant swaps + → - and / → _, and often drops the trailing = padding (which has its own URL meaning).
This is why a value encoded one way fails to decode the other way. If you paste a token and get garbage or an error, check which alphabet produced it. JWTs and many OAuth tokens use URL-safe Base64 without padding; copy-pasting them into a standard decoder is a common source of "invalid character" errors. This tool lets you switch alphabets so the same input decodes cleanly either way. If padding was stripped, a tolerant decoder can re-add it based on the string length.
Base64 operates on bytes, not characters, so before any text can be encoded it has to be turned into bytes — and the encoding you choose changes the result. A naive implementation that assumes one character equals one byte breaks the moment it meets anything outside Latin-1.
Take the euro sign €. In UTF-8 it is three bytes (E2 82 AC), which encode to 4oKs. The emoji 😀 is four bytes and encodes to 8J+YgA==. Encode them with the wrong byte conversion and you either lose data or get an exception.
This tool always converts text to and from UTF-8 for the byte step, so emoji, accented Latin, Cyrillic, CJK, and right-to-left scripts all round-trip correctly. If you paste Base64 that was produced from a different text encoding, the decoded characters may look wrong even though the byte-level decode succeeded — the bytes are right, but the assumed character set isn't UTF-8.
Beyond text, you can drop a file in to get its Base64 representation, or paste Base64 to download the reconstructed file. This is handy for building data URLs, pasting an image into a JSON request, or checking what a Base64 blob actually decodes to.
Keep two things in mind. First, size: Base64 inflates data by roughly a third, so a 1 MB file becomes about 1.33 MB of text. Inlining large assets as data URLs makes your HTML/CSS heavier and harder to cache, so reserve it for small files. Second, content type: a data URL needs the right MIME prefix (data:image/png;base64, vs data:application/pdf;base64,) or the browser won't know how to render it. Because the whole process happens in the browser, even large files are never uploaded — they're read into memory locally and the result stays on your machine.
No. It's a reversible encoding with a public, fixed alphabet, so anyone can decode it instantly. It provides zero confidentiality and should never be used to protect secrets.
Those are padding characters added when the input length isn't a multiple of 3, keeping the output length a multiple of 4. One leftover byte gives `==`, two leftover bytes give a single `=`.
URL-safe Base64 replaces `+` with `-` and `/` with `_` (and often drops `=` padding) so the result is safe inside URLs and filenames. A string encoded with one alphabet won't decode correctly with the other.
JWTs use URL-safe Base64 without padding. Switch to the URL-safe alphabet (or let the decoder re-add padding) and the header and payload will decode cleanly.
About 33% larger, because every 3 bytes of input become 4 characters of output. A 1 MB file encodes to roughly 1.33 MB of text.
Yes, as long as the text is converted to UTF-8 bytes first, which this tool does. For example `😀` (four UTF-8 bytes) encodes to `8J+YgA==` and decodes back exactly.
No. Encoding and decoding run entirely in your browser, so the text you paste and the files you drop never leave your device.
Yes. Encode the image file to Base64 and prefix it with the matching MIME type, e.g. `data:image/png;base64,<output>`, which you can drop straight into HTML or CSS.