Base64, encoded
and decoded

Convert text to Base64 or read it back, with correct UTF-8 handling and the URL-safe alphabet when you need it. Free, no sign-up required.

Standard Base64. Text is encoded as UTF-8 bytes first, so accented characters and emoji round-trip correctly.

Input

0 characters · 0 bytes

Output

0 characters · 0 bytes

Features

Everything you need to work with Base64 values.

Correct UTF-8 handling

Accented characters and emoji are encoded as UTF-8 bytes first, so they survive the round trip instead of throwing an error.

URL-safe alphabet

Switch to base64url, where + and / become - and _, for values that travel in a URL, a filename, or a JWT.

Converts as you type

No button to press. Character and byte counts sit under each panel so you can see the size cost of encoding.

Runs in your browser

Nothing is uploaded. Credentials, tokens, and anything else you paste stay on your machine.

How to encode or decode Base64

Three steps, and the result updates as you go.

Pick a direction

Encode turns text into Base64. Decode reads Base64 back into text, accepting either alphabet with or without padding.

Choose the options

URL-safe swaps the two problem characters. Padding controls whether the result is padded to a multiple of four with equals signs.

Copy or swap

The result appears as you type. Swap sends the output back into the input and reverses the direction.

When you need this

Where Base64 turns up in everyday work.

Reading a Basic auth header

Authorization: Basic values are just base64-encoded user:password. Decode one to see which account a request is using.

Inspecting a JWT segment

Each part of a token is base64url. Decoding a segment by hand shows exactly what a decoder is working from.

Embedding small assets

Data URIs carry an image or font inline as Base64. Encoding one here shows the size before you commit to it.

Debugging a config value

Kubernetes secrets and many CI variables store values as Base64. Decoding confirms what is actually being injected.

Understanding Base64

How the encoding actually works, why text has to become bytes before it can be encoded, when padding matters, and the security misconception that will not go away.

How the encoding works

Base64 regroups bits. Three bytes are 24 bits, and 24 divides evenly into four groups of six. Each six-bit group is a number from 0 to 63, which indexes into the 64-character alphabet: A-Z, then a-z, then 0-9, then + and /.

That is the entire algorithm. There is no compression, no transformation of the data, and nothing that depends on what the bytes mean.

input:   M         a         n
bytes:   01001101  01100001  01101110
regroup: 010011 010110 000101 101110
values:  19     22     5      46
output:  T      W      F      u

Because four output characters always encode three input bytes, the size increase is exactly 4/3, or about 33 percent before padding.

Why encoding text needs a character set first

Base64 encodes bytes, not characters. Before any text can be encoded, it has to be turned into bytes, and that requires choosing a character encoding.

Almost universally the right answer is UTF-8. The failure mode is a tool that assumes Latin-1, where every character is one byte: it works fine for plain English and then either throws or silently corrupts the first accented character it meets.

This is a real problem in JavaScript, where the built-in btoa function accepts only characters below U+0100 and throws on anything else. Encoding to UTF-8 bytes first is what makes non-Latin text work.

"é" as UTF-8   →  0xC3 0xA9  →  "w6k="
"é" as Latin-1 →  0xE9       →  "6Q=="

Both are valid Base64 of different byte sequences. If a decoded string comes out as mojibake, a mismatch of this kind is usually the cause.

Padding is optional, sometimes

The equals signs at the end exist so that a decoder reading a stream knows where a message ends and how many bytes the final group holds. When the length is already known, as it is for a value sitting in a JSON field, they carry no information.

That is why base64url normally omits them. JSON Web Tokens specify unpadded base64url precisely because the padding would need escaping in a URL for no benefit.

Decoders vary in strictness. Some accept unpadded input, some reject it, and some accept it only if the length is otherwise valid. Producing padded output is the safer default unless a specification says otherwise.

Where Base64 is worth the cost

The 33 percent size increase is real, so the encoding earns its place only where the channel genuinely cannot carry raw bytes.

Good uses include embedding a small icon as a data URI to avoid a network request, carrying binary payloads inside JSON, transmitting attachments through email, and moving certificates and keys around as PEM files, which are Base64 with header lines.

Poor uses include encoding large images inline, where you pay the size penalty and lose caching, and storing binary data in a database column that could have been a blob.

A rule of thumb: below a few kilobytes, inlining often wins by removing a request. Above that, the overhead starts to dominate.

Base64 is not a security measure

It is worth stating plainly because the mistake keeps recurring. Encoding a password in Base64 provides no protection whatsoever. The transformation is public, reversible, and takes microseconds.

HTTP Basic authentication is the canonical example. Credentials are base64-encoded, which stops them breaking the header syntax and does nothing else. Basic auth is only safe over TLS, where the transport provides the actual confidentiality.

If a value needs to stay secret, encrypt it. If it needs to be verified rather than hidden, sign it. Encoding solves a transport problem, not a security one.

Common questions

What is Base64?

Base64 is a way of representing arbitrary bytes using only 64 printable ASCII characters. Every three bytes of input become four characters of output. It exists so that binary data can travel through channels that only reliably carry text, such as email bodies, JSON strings, and URLs.

Is Base64 encryption?

No, and this matters. Base64 is an encoding, not a cipher. There is no key and no secret involved, so anyone can decode it instantly. Never use it to protect a password, a token, or anything else that needs to stay private.

What is base64url and when do I need it?

The standard alphabet includes + and /, which both have meaning inside a URL, and = which is used in query strings. The URL-safe variant replaces + with - and / with _, and usually drops the padding. JSON Web Tokens use it, as do many APIs that put encoded values into a path.

Why is my encoded string longer than the original?

Base64 turns every three bytes into four characters, so the output is about 33 percent larger, plus padding. That overhead is the price of being able to send bytes through a text-only channel, and it is why encoding large files inline is usually a poor trade.

What do the equals signs at the end mean?

They are padding. Base64 works in groups of three bytes, and when the input length is not a multiple of three the final group is padded so the output length is a multiple of four. One or two equals signs tell a decoder how many bytes of the last group are real.