Base64 rewrites any run of bytes using 64 plain characters, so data can travel through channels that only expect text: a URL, a JSON field, an email header. Three bytes go in and four characters come out, which makes the result about a third larger than what you started with.
It is an encoding, not encryption. Anything Base64 can hide, Base64 will hand straight back.
Base64 is about a third larger than what goes in. Nothing here leaves your browser.
Type in the left box and it converts as you go. Switch to Decode to read a string the other way, press URL-safe when the output has to survive a query string or a filename, and use Decode this to send the result back round for a round trip.
Base64 is not encryption
Worth being sure about, because it is the mistake that costs something. Base64 has no key and no secret. Every decoder on the internet, including the box above, will read it straight back.
| It is | It is not |
|---|---|
| A reversible mapping of bytes to text | Encryption |
| Fixed and keyless | Password protection |
| Slightly larger than the input | Compression |
| Readable by anyone holding it | A hash |
HTTP Basic authentication is the cautionary case. Authorization: Basic carries a
Base64 of username:password, which is why the scheme is only acceptable over
HTTPS. The encoding stops a colon confusing a parser. It stops nothing else.
The Base64 alphabet
Six bits index one character, so the table has 64 entries plus one symbol for padding.
| Values | Characters |
|---|---|
| 0-25 | A to Z |
| 26-51 | a to z |
| 52-61 | 0 to 9 |
| 62 | +, or - in URL-safe |
| 63 | /, or _ in URL-safe |
| padding | = |
Three bytes map to four characters, so the encoded length is always
ceil(bytes / 3) * 4, and = fills the gap when the input does not divide by
three.
| Input bytes | Encoded characters | Padding |
|---|---|---|
| 1 | 4 | == |
| 2 | 4 | = |
| 3 | 4 | none |
| 10 | 16 | == |
| 100 | 136 | == |
Standard and URL-safe Base64
Both are defined in RFC 4648. They differ in two characters, and those are exactly the two that cause trouble in a URL or a filename.
| Standard | URL-safe | |
|---|---|---|
| Section of RFC 4648 | §4 | §5 |
| Character 62 | + | - |
| Character 63 | / | _ |
| Padding | = | usually left off |
| Turns up in | data URLs, MIME, Basic auth | JWTs, query strings, filenames |
kitty? encodes to | a2l0dHk/ | a2l0dHk_ |
<meow> encodes to | PG1lb3c+ | PG1lb3c- |
The two alphabets never overlap, so a decoder can accept either without being told which it has. That is why the tool above only offers the choice when encoding.
Step by step
- Take the input as bytes. For text that means choosing a character encoding, and UTF-8 is both the one to use and the one this tool uses.
- Line the bytes up as one stream of bits, 8 bits per byte.
- Split the stream into groups of 6 bits instead of 8.
- Pad the last group with zero bits if it is short of 6.
- Read each group as a number from 0 to 63 and look it up in the alphabet.
- Append
=until the length is a multiple of 4.
Worked example
Cat is three bytes, so it divides evenly and needs no padding.
| Character | Byte | Bits |
|---|---|---|
C | 67 | 01000011 |
a | 97 | 01100001 |
t | 116 | 01110100 |
That is 24 bits, 010000110110000101110100, which re-splits into four groups of
six.
| Six bits | Value | Character |
|---|---|---|
010000 | 16 | Q |
110110 | 54 | 2 |
000101 | 5 | F |
110100 | 52 | 0 |
So Cat becomes Q2F0.
Hi is two bytes, which is where padding comes in. Sixteen bits make two full
groups of six with four bits spare, so those four are padded with two zero bits to
make 100100.
| Six bits | Value | Character |
|---|---|---|
010010 | 18 | S |
000110 | 6 | G |
100100 | 36 | k |
Three characters is not a multiple of four, so one = is appended and Hi
becomes SGk=.
When to use it
| Reach for it when | Avoid it when |
|---|---|
| Binary has to sit in a text field, like JSON or XML | The data needs to stay secret |
| Embedding a small image as a data URL | The payload is large and 33% is a real cost |
| Bytes have to survive a URL or filename, with base64url | You want it smaller, because this is not compression |
| Moving data through email, which is 7-bit by history | You need integrity, which is a hash or a signature |
Common questions
Is Base64 encryption?
No. Base64 has no key and no secret, so anyone holding the encoded string can decode it. It exists to move bytes through text-only channels, not to protect them. If the data needs to stay private, encrypt it, then Base64 the ciphertext if the transport requires text.
Why does Base64 end with = signs?
Base64 works in blocks of three bytes, which become four characters. When the input length is not a multiple of three the last block is short, and one or two = characters pad the output back to a multiple of four. One = means the final block held two bytes, two = means it held one.
What is the difference between Base64 and base64url?
Two characters. Standard Base64 uses plus and slash for values 62 and 63, and both have a meaning inside a URL. base64url uses hyphen and underscore instead, and usually drops the = padding because that has to be escaped too. JWT segments are base64url.
Does Base64 make data smaller?
The opposite. Every three bytes become four characters, so the encoded form is roughly 33 percent larger, plus padding. Base64 is an encoding, not compression. If size matters, compress the bytes first and encode the result.
Can I decode Base64 of an image or a PDF here?
Not usefully. This tool decodes to UTF-8 text, so a file produces bytes that are not text and the tool says so rather than showing a screenful of replacement characters. That message is a reliable sign you are holding an encoded file rather than an encoded string.
Is anything I paste here sent to a server?
No. The conversion runs in your browser and neither box is submitted anywhere. The site records that the tool was used, in which direction, and how many characters were involved, so we know which tools are worth building next. The text itself is never part of that.