What is Base64 and why use it?

Base64 represents binary data using 64 printable ASCII characters. It lets you move bytes safely through channels built for text - JSON fields, URLs, headers, and email - that would otherwise corrupt raw binary data.

Does Base64 make data larger?

Yes. Base64 encodes every 3 bytes as 4 characters, so the output is about 33% larger than the input. That size cost is the trade-off for text-safe transport; Base64 is not compression or encryption.

When should I use the URL-safe variant?

Standard Base64 uses + and / and = padding, which have special meaning in URLs. URL-safe Base64 replaces + with - and / with _ (and often drops padding) so the value can appear in a query string or path without extra escaping.

Does it handle emoji and non-English text?

Yes. Text is encoded as UTF-8 before Base64, so multi-byte characters and emoji round-trip correctly when decoded - unlike a naive btoa call that throws on characters outside Latin-1.

Are my files or text uploaded anywhere?

No. Encoding runs entirely in your browser using the File and TextEncoder APIs. Your text and files never leave your device, which makes the tool safe for sensitive data.

Base64 Encode

Stable

Encode text or files to Base64, with an optional URL-safe variant.

Everything is processed locally in your browser

About Base64 Encode

Convert text or binary files into Base64, the encoding used to embed data safely in JSON, data URLs, HTTP headers, and email. UTF-8 characters and emoji encode correctly, and you can switch to the URL-safe alphabet when the output must live inside a URL. Files are read and encoded locally, so nothing is ever uploaded.

Features

Encode plain text or drag-and-drop files of any type
Correct UTF-8 handling for accented characters, symbols, and emoji
URL-safe mode using - and _ instead of + and /, with optional padding removal
Generate ready-to-paste data: URLs for images and small assets
Live output that updates as you type, plus one-click copy
Byte and character counts for both input and encoded output

How to use Base64 Encode

1
Enter your input
Type or paste text, or drop a file into the tool. Binary files such as images are read as bytes and encoded directly.
2
Choose the alphabet
Use standard Base64 for most cases, or switch to URL-safe mode when the result will be placed in a URL or filename.
3
Copy the encoded output
The Base64 string updates instantly. Copy it, or copy it wrapped as a data: URL for direct use in HTML or CSS.

Examples

Encode a short string

Standard Base64 output for ASCII text.

Input

Hello, World!

Output

SGVsbG8sIFdvcmxkIQ==

How Base64 encoding works

Three bytes in, four characters out

Base64 works on groups of three bytes. Twenty-four bits divide evenly into four six-bit chunks, and each chunk indexes into a 64-character alphabet - `A-Z`, `a-z`, `0-9`, `+` and `/`. So every three bytes of input become exactly four characters of output, which is where the predictable 33% size increase comes from.

When the input length is not a multiple of three, the final group is short and gets padded. One leftover byte produces two characters plus `==`; two leftover bytes produce three characters plus `=`. That is why the `=` signs only ever appear at the end, and why their count tells you the original length modulo three.

Because six bits map to one of 64 printable ASCII characters, the output survives any channel that handles text. That is the entire purpose: Base64 exists so binary data can pass through systems that were only ever designed for text.

Base64 is not encryption, and the distinction is not pedantic

This is worth being blunt about because the mistake causes real breaches. Base64 is an encoding, not a cipher. There is no key, no secret, and nothing to break - decoding is a mechanical transformation that any tool performs instantly. Base64-encoded text is exactly as public as the original.

The confusion is understandable, since the output looks scrambled. But `cGFzc3dvcmQ=` is not a protected version of `password`; it is the same information in a different alphabet. HTTP Basic authentication encodes credentials this way purely so they survive as a header value, which is precisely why Basic auth requires TLS - the encoding contributes no confidentiality whatsoever.

So never Base64 something to hide it. If you need confidentiality, encrypt with AES-GCM or similar, and then Base64 the ciphertext if it has to travel as text. Encoding is the transport layer, not the protection layer.

Standard and URL-safe alphabets

The standard alphabet's last two characters, `+` and `/`, are both problematic in URLs: `/` is a path separator and `+` is interpreted as a space in query strings by many decoders. So RFC 4648 defines a URL-safe variant that substitutes `-` and `_`, leaving everything else identical.

The padding is usually dropped in the URL-safe variant too, because `=` needs percent-encoding in a query string. Padding is not needed to decode - the length already determines it - so omitting it is safe as long as the decoder tolerates unpadded input.

JSON Web Tokens use exactly this variant, which is why a JWT contains `-` and `_` but never `+`, `/` or `=`. If you are hand-decoding a JWT segment with a standard Base64 decoder, this is the mismatch you will hit.

Text has to become bytes before it can be encoded

Base64 encodes bytes, not characters, so text must be converted to bytes first - and that requires choosing an encoding. Practically that always means UTF-8. Choose differently at either end and you get mojibake, because the decoder reassembles the correct bytes and then misreads them.

This is the source of the classic JavaScript failure. The legacy `btoa()` function operates on Latin-1 and throws an `InvalidCharacterError` on any character above U+00FF, so `btoa("café")` fails outright. The modern approach is to encode with `TextEncoder` first and Base64 the resulting bytes, which handles the full Unicode range correctly.

Reference

Base64 variants

Variant	Last two characters	Padding	Used by
Standard (RFC 4648 §4)	+ and /	= required	MIME, HTTP Basic auth, data URIs
URL-safe (RFC 4648 §5)	- and _	Usually omitted	JWTs, URLs, filenames
MIME (RFC 2045)	+ and /	= required	Email, with line breaks every 76 characters

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need to embed binary data in JSON, XML or a data URI: Base64 is the standard answer, and this is what it was designed for.
The result goes in a URL or a filename: Use the URL-safe variant, or `+` and `/` will be mangled.
You want to protect sensitive data: Base64 provides no protection at all. Encrypt it, then Base64 the ciphertext if it must travel as text.
You need to escape a string for a URL: The URL Encode tool is the right one. Percent-encoding keeps text readable, which Base64 does not.
You need a fingerprint of the data: The Hash Generator produces a fixed-length digest. Base64 is reversible by design and is not a fingerprint.

Use cases

Embedding small images or fonts inline as data: URLs
Encoding binary payloads so they can travel inside JSON or XML
Building HTTP Basic Authorization header values
Storing binary blobs in text-only systems and config files
Preparing attachments for MIME email bodies

Troubleshooting common errors

btoa() throws InvalidCharacterError

Why: `btoa` only handles Latin-1, and any character above U+00FF is out of range.

Fix: Convert to bytes with `new TextEncoder().encode(str)` first, then Base64 those bytes.

The encoded string breaks when placed in a URL

Why: The standard alphabet contains `/` and `+`, which are meaningful in URLs.

Fix: Use the URL-safe variant with `-` and `_`, and drop the padding.

The payload is a third larger than the original

Why: Inherent to the encoding - four output characters per three input bytes.

Fix: Expected. Where size matters, send binary directly with a `multipart/form-data` upload rather than encoding it.

Accented characters come back wrong after a round trip

Why: Different text encodings at each end, or Latin-1 assumed somewhere in the chain.

Fix: Use UTF-8 on both sides and state it explicitly. This is a text-encoding bug, not a Base64 bug.

The decoder rejects your output

Why: Usually a padding or variant mismatch - a strict decoder wanting `=` that you omitted, or standard characters where URL-safe were expected.

Fix: Match the variant to the consumer. JWT libraries expect URL-safe and unpadded.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Output is always about 33% larger than the input.
Base64 provides no confidentiality whatsoever - it is trivially reversible.
Text must be converted to bytes first, and the encoding must match at both ends.
Standard and URL-safe variants are not interchangeable.
Very large files are limited by browser memory, since the whole input is held at once.

Frequently asked questions

Base64 Decode

Decode Base64 back to readable text, including URL-safe input.

URL Encoder

Percent-encode text for safe use in URLs and query strings.

Hash Generator

Compute SHA-1, SHA-256, SHA-384, and SHA-512 hashes of text or files.

JWT Decoder

Decode a JWT to inspect its header, payload, and claims instantly.

Learn more

How to Base64 Encode Text and Files (and Get UTF-8 Right)Base64 encoding turns arbitrary bytes into safe, portable text. This guide covers how encoding works, UTF-8 pitfalls, URL-safe output, and how to encode text or files without uploading anything.