Part of Text tools: See all Text tools.
Base64: Base64 encode and decode text instantly. Convert strings to Base64 for APIs, data URLs, or encoding—and decode Base64 back to plain text.
Quick steps
- Paste your text in the input area.
- 'Encode' to convert to Base64 or 'Decode' to convert from Base64.
- Copy the result or use it in your application.
Base64 vs desktop software
| Feature | Base64 | Desktop software |
|---|---|---|
| Install required | No | Yes |
| Works on phone & desktop | Yes | Varies |
| Free to use | Yes | Often paid |
| Signup needed | No | Sometimes |
People also ask
Is this tool free?
Yes. No limits or signup.
Is my data secure?
Encoding runs locally. Your text is never sent to our servers.
What character set is used?
Standard Base64 (A-Z, a-z, 0-9, +, /, =).
What is Base64?
Base64 encode and decode text instantly. Convert strings to Base64 for APIs, data URLs, or encoding—and decode Base64 back to plain text.
How to use Base64
- Paste your text in the input area.
- Click 'Encode' to convert to Base64 or 'Decode' to convert from Base64.
- Copy the result or use it in your application.
Why use this tool?
Base64 encoding is used in APIs, emails, and embedding small files in HTML or CSS. Developers often need to encode decode Base64 for authentication headers, data URLs, and binary-safe transfer. A free Base64 encoder decoder saves time during development and troubleshooting.
Where you'll see it: Base64 shows up in data URLs, embedded payloads, and debugging contexts where you need text-safe encoding.
When decoding, treat output as text if it's UTF-8; if you're working with binary content, you may need a different workflow.
FAQ
- Is this tool free?
- Yes. No limits or signup.
- Is my data secure?
- Encoding runs locally. Your text is never sent to our servers.
- What character set is used?
- Standard Base64 (A-Z, a-z, 0-9, +, /, =).
Base64 — In-Depth Guide
Base64 encoding converts binary data into a safe ASCII text representation using 64 characters. Developers use it constantly when working with APIs that transmit data as JSON or XML, since these formats cannot handle raw binary content. Encoding authentication tokens, small images, and file attachments in Base64 is standard practice across web development.
Email systems have used Base64 encoding since the early days of the internet through the MIME standard. Email attachments are Base64-encoded for transmission and decoded by the receiving email client. Understanding Base64 helps when debugging email delivery issues or examining raw email headers and attachment content.
Web developers embed small assets directly in HTML and CSS using Base64 data URIs. This technique reduces HTTP requests for tiny icons and background images. However, Base64 increases the encoded size by approximately 33 percent, so it is best reserved for assets under 5 KB where the reduced latency outweighs the size increase.
When decoding Base64 strings, ensure the input is properly formatted with correct padding characters. Base64 strings use the equals sign for padding and should contain only letters, digits, plus signs, and forward slashes. URL-safe Base64 variants replace plus and slash with hyphen and underscore to avoid issues in URLs and filenames.
What Base64 is actually for
Base64 is a way of representing arbitrary binary data using only the 64 printable ASCII characters A–Z, a–z, 0–9, plus, and slash (with equals used as padding). It exists because large parts of the internet — email headers, URLs, XML attributes, JSON values, HTTP cookies — were designed for text and cannot reliably carry raw bytes. An image is a stream of bytes with control characters, null bytes, and high-bit values that corrupt when passed through text-only channels. Base64 turns that stream into an innocent-looking string like iVBORw0KGgoAAAANSUhEUgAA... that survives any text transport.
The encoding adds about 33% overhead — three bytes of binary become four bytes of Base64 — which is why it is almost never used when a binary transport is available. HTTP handles binary perfectly well, so you send an image as an HTTP response body, not as a Base64 string. Email attachments, SMTP, and XML payloads are where Base64 still earns its place.
The encoding, in plain terms
Take three bytes of input. Each byte is 8 bits, so that is 24 bits total. Split those 24 bits into four 6-bit groups. Each 6-bit group has 64 possible values — which is exactly the size of the Base64 alphabet, by design. Look up each group in the alphabet to get four printable characters. Repeat for every three-byte chunk.
When the input length is not divisible by three, the final chunk gets padded. If one byte is left over, it produces two meaningful characters and two equals signs. If two bytes are left over, it produces three meaningful characters and one equals sign. The equals signs do not encode data; they tell the decoder "the last group was partial, stop here". If you see a Base64 string with no equals signs, its length is a multiple of four; if it ends with = or ==, it had leftover bytes.
Where you actually see Base64 in the wild
Email attachments: when you attach a PDF to an email, the MIME encoder wraps it in Base64 and sets Content-Transfer-Encoding: base64. This is invisible to you and the recipient but adds 33% to every attachment. That is one reason emailing a 25 MB PDF sometimes runs into a 25 MB limit: the transport size is larger than the file size.
Data URLs: data:image/png;base64,iVBORw0KGgo... is a URL that contains the entire image inline. Browsers decode it into raw bytes and render the image with no separate HTTP request. Useful for tiny UI assets (sub-kilobyte icons, email signature logos) where the HTTP round-trip cost exceeds the Base64 overhead. Terrible for anything large because the 33% overhead compounds with the fact that the URL lives in HTML, and HTML does not gzip as well as raw binary.
JWT tokens: the access tokens your browser receives after logging in are three Base64-encoded segments separated by dots. The first segment is the header, the second is the claims payload, the third is the signature. Decoding the middle segment shows you exactly what the server knows about your session — issuer, expiration, scopes. JWTs use a URL-safe variant of Base64 that swaps +/ for -_, which is important to know: a standard Base64 decoder chokes on URL-safe input unless you map the characters first.
API keys and credentials: AWS signature strings, basic-auth headers, OAuth state parameters, and CSRF tokens are frequently Base64-encoded because they need to fit into HTTP headers and URLs without escaping.
Base64 is not encryption
This sounds obvious but the mistake is common enough to warrant stating directly: Base64 is not a security measure. Anyone can decode it in two seconds. If a password, API key, or sensitive token is "protected" by Base64 encoding, it is not protected. The encoding prevents corruption during transport; it does nothing against an adversary with a decoder.
If you see a "decoded" string that still looks like gibberish, there are three likely explanations: the input was encoded with URL-safe Base64 and you are using standard decoding; the input was actually compressed, then Base64-encoded (decode Base64, then gunzip); or the input was encrypted, then Base64-encoded (decode Base64, then decrypt — you need the key).
File encoding and size considerations
Base64-encoding a 1 MB file produces roughly 1.33 MB of output. For very small files (a 32-pixel icon, a tiny logo), the ratio can be worse because the padding overhead is larger relative to the payload. For large files, the ratio is almost exactly 4/3 regardless of content type, because that is a fixed property of the encoding.
There is no meaningful compression inside Base64 itself — the encoding is byte-for-byte deterministic. If you need both a text-safe representation and a smaller size, gzip the file first and then Base64-encode the gzipped result. For structured data like JSON, gzip typically shrinks the payload to 20–30% of the original, so the Base64 of the gzipped payload ends up around 27–40% of the original raw size. This is the pattern used for compressed HTTP headers, some auth tokens, and export formats that need to fit into a fixed field size.
Standard vs URL-safe vs MIME Base64
Three Base64 variants circulate in practice. Standard uses the alphabet A–Z a–z 0–9 + / with = padding. URL-safe replaces + with - and / with _, so the output is safe to drop directly into a URL query string without percent-encoding. Some URL-safe encoders also omit the trailing = padding. MIME is standard Base64 with mandatory line breaks every 76 characters, which is required by email transport.
Mixing variants is a classic source of "why does this not decode" bugs. A JWT (URL-safe, no padding) pasted into a standard decoder will fail on the first - or _. An email attachment (MIME, with line breaks) pasted into a strict decoder will fail on the first newline. If the decode seems to be complaining, the first debugging step is: what variant is this?
Decoding to text, decoding to binary
The other common decoding confusion is whether the decoded bytes should be interpreted as text or as binary. Base64 decoding always produces raw bytes; whether those bytes are a UTF-8 string, a JPEG header, or a zipfile is a property of what was encoded, not of the decoding process. This tool shows you both views: the raw byte sequence and — if the bytes happen to be valid UTF-8 — the decoded text. If the text view is mojibake (†sequences, black diamonds with question marks), the decoded bytes are not text at all, and you should download them as a file instead.
Binary outputs are common when people paste random Base64 strings they found: JWT signature sections, encoded PNGs, encoded GZIP payloads. The tool offers to download decoded bytes as a file so you can save an encoded image back to disk, or pass the decoded GZIP through a decompressor. A surprising number of "decode this for me" debugging sessions end with "oh, it's a gzipped protobuf wrapped in Base64" — two nested layers that are invisible until you unpeel them one at a time.
Why browser-side decoding matters for tokens
The most sensitive real-world Base64 payloads are auth tokens: JWTs in Authorization headers, OAuth state parameters, CSRF double-submit cookies. Pasting any of these into a random online decoder is a small but real security concern — the decoder operator sees the token, and depending on what it encodes, they might see user IDs, session scopes, issuer identities, or audience claims. This tool performs the decode in your browser using the native atob function. The token does not leave your machine. The network tab in your browser's devtools will confirm that no request is fired when you paste or decode.
Also try
Related tools that work well with this one: