Base64 Encoder & Decoder

Base64 works on bytes, not directly on characters. For plain English, this difference is easy to miss, but for Hindi, emoji, accents, or symbols, you must first convert the text to UTF-8 bytes and then Base64-encode those bytes. In modern JavaScript, use TextEncoder before encoding, or use a tool that clearly supports UTF-8. If you use older btoa directly on Unicode text, you may get errors or wrong output. When decoding, reverse the process: Base64 to bytes, then UTF-8 text.

Base64 usually increases size by about one third. Technically, it turns every 3 bytes of input into 4 encoded characters, so the output is roughly 33 percent larger, plus a little padding when the input length is not a multiple of 3. If line breaks are inserted, the text can grow slightly more. This is fine for small images, tokens, and snippets, but it is not efficient for large files. For big downloads or uploads, send the binary file directly instead of wrapping it in Base64.

First create a cryptographic hash of the file, such as SHA-256. That gives you raw digest bytes. Then encode those digest bytes in Base64. This is different from Base64-encoding the whole file. A Base64 hash is just a compact text representation of the checksum, commonly used in integrity attributes, APIs, and security headers. Make sure you and the receiving system agree on the algorithm and encoding format. A SHA-256 digest in hex will not look the same as the same digest in Base64.

Yes. Base64 is commonly used to represent binary data as text, so PNG, PDF, MP3, ZIP, and other files can be encoded. The result is safe to store in JSON, copy into text fields, or place in a data URI when appropriate. Just remember that the output is larger than the original file and is not encrypted. Anyone can decode it back to the original bytes. For large media files, Base64 is usually less efficient than storing the file normally and linking to it.

The equals signs are padding. Base64 processes input in groups of 3 bytes and outputs 4 characters. If the final group has only 1 or 2 bytes, padding is added so the output length still lines up correctly. One = or two == characters simply tell the decoder how many bytes were missing at the end. Some Base64URL systems omit padding, but standard Base64 often includes it. Do not remove padding unless you know the receiving system accepts unpadded Base64.

First convert the JSON object to a string using a stable JSON representation, usually JSON.stringify. Then convert that string to UTF-8 bytes and Base64-encode the bytes. On decode, do the reverse: Base64-decode to bytes, read as UTF-8 text, then JSON.parse. Be careful not to treat Base64 as security. It only hides the JSON from casual reading; it does not protect secrets. If the JSON contains sensitive data, use encryption or signed tokens, depending on your use case.

There is no single safe maximum that works perfectly across all browsers, devices, and contexts. Data URIs are best for small assets, such as tiny icons or test images. Large Base64 data URIs can make HTML or CSS heavy, slow down parsing, increase memory use, and hit practical URL or attribute limits in some environments. For production, use normal files for larger images, audio, video, or downloads. If you must use a data URI, test it in the exact browsers and webviews your users rely on.

Use a browser-based Base64 tool that reads the selected file locally with the File API. The browser converts the file bytes to Base64 on your device, so the file does not need to be uploaded just to encode it. This is useful for quick data URIs, API testing, or embedding small files in JSON. For very large files, the page may become slow because Base64 output is bigger and memory-heavy. Also remember that Base64 is reversible, so do not treat it as data protection.

Most decoders can ignore line breaks if the Base64 content is otherwise valid. Remove surrounding labels, spaces, and headers first, then decode the actual Base64 body. This is common with PEM files, emails, and copied terminal output. If decoding fails, check for missing padding, non-Base64 characters, smart quotes, or accidental spaces in the middle of the text. Also confirm whether the input is standard Base64 or Base64URL, because Base64URL uses - and _ instead of + and /.

Garbled text usually means the decoded bytes are not being interpreted with the right character encoding, or the original data was not text at all. Base64 can represent images, PDFs, compressed files, encrypted data, or UTF-16 text, not just UTF-8 strings. First decode the Base64 into bytes. Then decide what those bytes are: text, image, audio, zip, or another format. If it is text, try UTF-8 first. If it still looks wrong, check the source encoding or whether the data was compressed before encoding.