BrowserTools
Advertisement
Home / Encoders / Base64 Encoder & Decoder

Base64 Encoder & Decoder

Encode and decode Base64 text or files locally in your browser.

Loading Base64 Encoder & Decoder… If nothing happens, please enable JavaScript.

Frequently asked questions

Is my data uploaded to a server?
No. All encoding and decoding happens locally in your browser using the Web platform's built-in btoa/atob and FileReader APIs. Your text, files, and any sensitive values never leave your device and are never transmitted over the network.
What exactly are those 64 characters Base64 uses?
The standard alphabet defined in RFC 4648 uses A–Z (26 characters), a–z (26 characters), 0–9 (10 characters), plus + and / — totalling 64. The = character is used as padding to make the output length a multiple of 4. The URL-safe variant replaces + with - and / with _ so the output is safe in URLs and filenames without further escaping.
When should I use Base64 encoding in my own projects?
Use Base64 whenever you need to embed binary data inside a text-only format: embedding images as data URIs in HTML or CSS, storing binary blobs in JSON or XML, sending files in a JSON API body, or including cryptographic keys in environment variables. Avoid it when you can use a binary-capable transport, since Base64 adds a 33 % size overhead.
How does Base64 compare to hex encoding?
Both convert binary data to printable text, but they differ in density. Hex uses 2 characters per byte (50 % overhead), while Base64 uses roughly 1.33 characters per byte (33 % overhead), making Base64 about 25 % more compact. Hex is easier to read and widely used for checksums and colour codes; Base64 is preferred when compactness matters or when the output will be embedded in structured text formats.
What is the maximum file size I can encode or decode?
There is no hard-coded limit, but practical constraints apply. Very large files (tens of megabytes) are held entirely in browser memory as a string, which can cause slowdowns or out-of-memory errors on low-RAM devices. For most use cases up to a few megabytes the tool is fast and responsive. For bulk or large-file workflows a command-line tool like base64 (Linux/macOS) or certutil -encode (Windows) is more suitable.
Does it work offline and in all modern browsers?
Yes. The tool uses only standard Web APIs (btoa, atob, FileReader, TextEncoder) that have been available in every major browser since 2012. There are no external requests, so it works fully offline once the page has loaded. Performance is determined by your device's CPU and available RAM.
Can I encode binary files such as images or PDFs?
Yes. Use the file input to select any binary file. The FileReader API reads it as an ArrayBuffer, which is then converted to a Base64 string without any character-encoding issues. The resulting string can be pasted directly into a data URI (prefix it with data:image/png;base64, for a PNG, for example) or used anywhere else Base64-encoded binary is expected.
Is Base64 a form of encryption?
No — Base64 is purely an encoding scheme, not encryption. It provides zero confidentiality: anyone who sees the encoded string can decode it instantly without any key or password. Do not use Base64 to protect sensitive data. Use proper encryption (AES, RSA, etc.) for confidentiality, and only use Base64 as the transport or storage format after the data has been encrypted.
What is the difference between standard Base64 and Base64url?
Standard Base64 (RFC 4648 §4) uses + and / as the 62nd and 63rd characters, which have special meaning in URLs and must be percent-encoded. Base64url (RFC 4648 §5) replaces + with - and / with _, making the output safe to include in URLs, filenames, and HTTP headers without escaping. JSON Web Tokens always use Base64url. This tool's URL-safe toggle applies that substitution automatically.
Why do I sometimes get an 'invalid character' error when decoding?
This usually means the input contains characters outside the Base64 alphabet — often whitespace, newlines, or a data URI prefix like 'data:image/png;base64,'. Strip any such prefix before decoding. Another common cause is a URL-encoded string where + has been replaced by a space; in that case switch to URL-safe mode or manually replace spaces with + before decoding.

About Base64 Encoder & Decoder

Base64 is a binary-to-text encoding scheme that represents binary data using only 64 printable ASCII characters — the uppercase and lowercase Latin alphabet, the digits 0–9, and the symbols + and /. It was standardised in 1987 as part of RFC 989 for Privacy Enhanced Mail, and later formalised in RFC 4648. The name comes from the fact that each output character encodes exactly 6 bits, meaning every 3 bytes of binary input become exactly 4 ASCII characters — a 33 % size overhead that is well worth the compatibility gain.

Developers reach for Base64 every day without always realising it. Data URIs that embed images or fonts directly in HTML and CSS use Base64. JSON Web Tokens use Base64url (a URL-safe variant) to pack their header and payload. HTTP Basic Authentication encodes credentials as Base64 before placing them in the Authorization header. TLS certificates, SSH keys, and PGP armored messages are all distributed as Base64-wrapped PEM files. Any time binary data must survive a text-only transport or storage layer — email, JSON, XML, environment variables — Base64 is the standard answer.

This tool encodes and decodes Base64 entirely inside your browser. It uses the platform's built-in btoa/atob functions for text and the FileReader API for binary file uploads. Because all processing happens on your own device, your data is never transmitted to any server — making it safe to use with sensitive credentials, private keys, or confidential documents. The tool also supports URL-safe Base64, which replaces + with - and / with _ so that the output can be embedded in URLs without percent-encoding.

A few things to watch out for: btoa throws a TypeError if the input contains characters outside the Latin-1 range, so the tool automatically UTF-8 encodes Unicode text before encoding. When decoding, trailing padding characters (=) are optional in many implementations but some strict parsers require them — if you receive a decoding error, try appending one or two = signs. Base64 is an encoding, not encryption: it provides zero confidentiality, and anyone can decode it instantly. Never store passwords or tokens in Base64 expecting any security benefit.

The origins of Base64

Base64 was standardised in 1987 as part of RFC 989, which defined Privacy Enhanced Mail (PEM) for secure email exchange. The name comes from the fact that the encoding uses exactly 64 printable ASCII characters — the largest power-of-two subset that fits comfortably in most character encodings of the era. The scheme was later refined in RFC 1421 and definitively documented in RFC 4648 (2006), which remains the authoritative reference today.

Before Base64, sending binary data over email systems was notoriously unreliable. Early mail relays operated on 7-bit ASCII and would silently corrupt bytes above 127, treating them as control codes or stripping the high bit entirely. Base64 solved this by mapping every 3 bytes of binary input into 4 printable characters drawn from a safe, universally supported subset of ASCII, guaranteeing faithful transit through any text-only channel.

Today, Base64 is woven into the fabric of the web. A modern browser processes thousands of Base64 operations per page load without the user ever noticing — decoding font files embedded in CSS, verifying JWT tokens in API responses, rendering inline images in email clients, and validating TLS certificates during the HTTPS handshake. What began as a workaround for flawed 1980s mail infrastructure has become one of the most quietly essential encodings in computing.

Advertisement