Base64 Encoder & Decoder
Convert text to Base64 and decode Base64 back to text, in the standard or URL-safe alphabet.
By Jack Shi · Updated October 11, 2026
The text you type is encoded and decoded in your browser by the tool; it is not sent anywhere for conversion.
- Base64 writes any bytes as text: every 3 bytes become 4 characters from a 64-character alphabet, so the result is about one third longer.
- The = at the end is padding for a last group with fewer than 3 bytes. One leftover byte gives ==, two give =.
- URL-safe Base64 (base64url) swaps + / for - _. JWTs use it without the padding.
- Text is turned into UTF-8 bytes before encoding, so accented letters and emoji take more than one byte each.
- Base64 is not encryption. There is no key, and anyone can decode it.
Computers store text as bytes, and a byte is 8 bits. Base64 re-reads the same bits in chunks of 6, because 6 bits can take 64 different values (0 to 63), and each value is written as one printable character. The tool does this three bytes at a time: 3 bytes are 24 bits, and 24 bits are exactly four 6-bit chunks.
Take the three-letter text Man. The numbers below are computed by the same code as the tool.
| Step | Value |
|---|---|
| 1. Bytes | M a n = 77, 97, 110 |
| 2. As 8-bit groups | 01001101 01100001 01101110 |
| 3. Same 24 bits, in 6-bit groups | 010011 010110 000101 101110 |
| 4. Each group as a number | 19, 22, 5, 46 |
| 5. Look up in the alphabet | T W F u → TWFu |
Step 5 uses the alphabet below. The numbers are the position in each row, counted from the start value on the left.
| Values | Characters (in order) |
|---|---|
| 0 to 15 | ABCDEFGHIJKLMNOP |
| 16 to 31 | QRSTUVWXYZabcdef |
| 32 to 47 | ghijklmnopqrstuv |
| 48 to 63 | wxyz0123456789+/ |
Decoding is the same arithmetic in reverse: look each character up to get its 6-bit value, join the bits, and cut them into 8-bit bytes. Here is the alphabet from RFC 4648, Table 1: values 62 and 63 are + and /, and = is not part of the 64.
If the input is not a multiple of three bytes, the last group is short. Zero bits are added on the right to fill the last 6-bit chunk, and = characters pad the output to a multiple of four. The same steps for two and one byte:
| Text | 6-bit groups (zero bits added on the right) | Result |
|---|---|---|
| Ma | 010011 010110 000100 | TWE= |
| M | 010011 010000 | TQ== |
The output length is 4 × (bytes divided by 3, rounded up) when padding is kept. Without padding it is the number of bits divided by 6, rounded up.
| Input bytes | Characters with padding | Characters without padding |
|---|---|---|
| 1 | 4 | 2 |
| 2 | 4 | 3 |
| 3 | 4 | 4 |
| 4 | 8 | 6 |
| 5 | 8 | 7 |
| 6 | 8 | 8 |
| 10 | 16 | 14 |
| 100 | 136 | 134 |
| 1000 | 1336 | 1334 |
That is the cost of Base64: about 33% more characters. If your system can carry bytes directly, there is no reason to encode them.
Standard Base64 uses + and / for values 62 and 63. Both have special meanings in URLs and file names, so RFC 4648 section 5 defines a second alphabet, which it says may be called “base64url”, where - and _ take their place. Everything else is identical. The RFC also says it should not be called just “base64”.
Padding is a separate choice. The RFC says implementations must include padding unless the specification using it says otherwise. JSON Web Signature, the format behind JWTs, does say otherwise: its RFC 7515 definition of “Base64url Encoding” is the URL-safe alphabet with all trailing = characters omitted. In the tool, choose “URL-safe” and “Omit = padding” to produce that form. When you decode, the tool recognises either alphabet by itself.
- HTTP Basic authentication. The user-id and password are joined with a colon and Base64-encoded into the Authorization header (RFC 7617). This hides nothing, so it must travel over HTTPS.
- Email attachments. MIME uses Base64 so binary files can pass through text-only mail systems, with lines limited to 76 characters.
- JWTs. The header and payload are base64url text, which is why you can read a token’s contents without any key.
- Embedding small data in text formats such as JSON, XML or a data: URL, at the price of about one third more size.
It is not a way to protect data. A Base64 string is readable by anyone who runs a decoder, including this page. When something must stay secret, use real encryption such as AES, not an encoding.
Each result below is produced by the same code as the tool. Published test vectors, boundary cases and pitfalls are included on purpose.
Published: "foobar" from RFC 4648 section 10
Encode foobar with the standard alphabet, padding kept:
Zm9vYmFy
Six bytes make exactly two full groups of three, so there is no = padding. RFC 4648 lists this as one of its seven test vectors.
Published: "fooba" from RFC 4648 section 10
Encode fooba with the standard alphabet, padding kept:
Zm9vYmE=
Five bytes leave a final group of two bytes (16 bits), which gives three characters and one = pad.
Published: "foob" from RFC 4648 section 10
Encode foob with the standard alphabet, padding kept:
Zm9vYg==
Four bytes leave a final group of one byte (8 bits), which gives two characters and two = pads.
Published: the HTTP Basic credentials example in RFC 7617
Encode Aladdin:open sesame with the standard alphabet, padding kept:
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
RFC 7617 sends the user-id and password joined by a colon, Base64-encoded, in the Authorization header. Anyone who sees the header can decode it, which is why Basic authentication needs HTTPS.
Typical: a short ASCII greeting
Encode Hello World with the standard alphabet, padding kept:
SGVsbG8gV29ybGQ=
Eleven bytes: three full groups and a final group of two bytes, so the result ends in one =.
Typical: decoding it back
Decode SGVsbG8gV29ybGQ=:
Hello World
The decoder strips the = pad, reads the characters as 6-bit values and regroups them into bytes.
Boundary: empty input
Encode (empty input) with the standard alphabet, padding kept:
(empty output)
Zero bytes encode to the empty string. RFC 4648 lists BASE64("") = "" as its first test vector.
Boundary: decoding without the = padding
Decode SGVsbG8gV29ybGQ:
Hello World
The tool accepts text whose = padding was dropped, because the length of the last group still tells how many bytes it held. RFC 4648 says padding must be written unless the protocol states otherwise, so a strict decoder may reject this.
Typical: non-ASCII text is encoded as UTF-8 bytes
Encode café ✓ with the standard alphabet, padding kept:
Y2Fmw6kg4pyT
The é takes two bytes and the check mark takes three, so these six characters are nine bytes and encode to twelve Base64 characters. Base64 encodes bytes, so the text is turned into UTF-8 bytes first.
Typical: the same text in the URL-safe alphabet
Encode Is it ok?>> with the URL-safe alphabet, padding omitted:
SXMgaXQgb2s_Pj4
In the standard alphabet this text encodes to SXMgaXQgb2s/Pj4=. The URL-safe alphabet writes _ where the standard one writes /, and base64url as used in JWT leaves the = off. Decoding needs no setting: the tool recognises either alphabet.
Limit: this is not encryption
Decode cGFzc3dvcmQ6IGh1bnRlcjI=:
password: hunter2
Decoding needs no key. Never put a secret in Base64 and call it hidden.
Pitfall: decoding binary data as text
Decode /9j/:
ff d8 ff (3 bytes, not valid UTF-8 text)
These three bytes (ff d8 ff) are how a JPEG file starts. They are not valid UTF-8, so the tool shows the bytes as hex instead of garbled text.
Pitfall: a character outside the alphabet
Decode SGVs*bG8=:
Error: Invalid character "*": Base64 only allows A-Z, a-z, 0-9, + and / (or - and _), plus = at the end.
RFC 4648 tells decoders to reject characters outside the alphabet unless the protocol says otherwise. MIME is the usual exception: it ignores them. Line breaks and spaces are dropped by this tool before decoding.
RFC 4648 (October 2006, obsoleting RFC 3548) describes the Base16, Base32 and Base64 encodings. Its introduction explains why it exists: protocols had been using “base64” without a precise description, often pointing at MIME without considering line-wrapping or non-alphabet characters, and the document sets out to establish a common alphabet and common rules.
The RFC also records where the older rules came from. MIME inherits the encoding from Privacy Enhanced Mail (PEM), which it calls “virtually identical”; MIME limits lines to 76 characters and PEM to 64, and both limits are due to limits within SMTP. For that reason RFC 4648 says implementations must not add line feeds unless the specification using it says to, and that decoders must reject characters outside the alphabet unless the specification says otherwise. MIME is the standard example of a specification that says otherwise, by ignoring them.
This tool follows the alphabet and the padding arithmetic of RFC 4648 and checks its output against the RFC’s seven test vectors. It is more lenient than a strict decoder in one way: it accepts input with the = padding missing, and it ignores spaces and line breaks.
What is Base64 encoding?
Base64 turns any sequence of bytes into text made of 64 printable characters (A-Z, a-z, 0-9, + and /), with = used as padding. Every 3 bytes become 4 characters. It exists so binary data can travel through systems that only handle text, such as email and JSON. RFC 4648 is the standard that defines it.
How does Base64 work, step by step?
Write the bytes as bits, take them 24 bits at a time (three bytes), cut each 24-bit group into four 6-bit pieces, and look up each piece (a number from 0 to 63) in the alphabet. The text "Man" is the bytes 77, 97, 110; as bits 01001101 01100001 01101110; regrouped as 010011 010110 000101 101110, which are 19, 22, 5, 46, the characters T, W, F, u. So "Man" is "TWFu".
What does the = at the end mean?
The input is cut into groups of three bytes, so when the last group has only one or two bytes, zero bits are added to fill the 6-bit pieces and = characters fill the output up to a multiple of four. One leftover byte gives two characters and "==", two leftover bytes give three characters and "=". If the byte count is a multiple of three, there is no padding.
Is Base64 encryption? Is it secure?
No. Base64 is an encoding, not encryption: there is no key, and anyone can decode it. Do not use it to hide passwords, API keys or personal data. It does not protect anything; it only changes the representation of the bytes.
Why does Base64 make my data bigger?
Three bytes become four characters, so the size grows by about one third. The exact length is 4 times the number of bytes divided by three, rounded up, when padding is kept. For example, 1000 bytes become 1336 characters with padding and 1334 without it. Wrapping the output in lines, as MIME does, adds line breaks on top.
What is URL-safe Base64 (base64url)?
It is the same encoding with two characters swapped: - replaces + and _ replaces /, because + and / have special meanings in URLs and file names. RFC 4648 section 5 defines it. JSON Web Signatures (the JWT format) use it with the trailing = removed. The tool can encode in either alphabet and decodes either one automatically.
Why does my text with accents or emoji produce a longer result?
Base64 works on bytes, and text is first turned into UTF-8 bytes. Letters like é take two bytes and many symbols take three or four, so "café ✓" is six characters but nine bytes and encodes to twelve Base64 characters.
Why does decoding give an error?
The tool rejects text that cannot be valid Base64: characters outside the alphabet, a mix of + / and - _, = anywhere except the end, more than two =, or a length that leaves a single stray character. Spaces and line breaks are ignored, and missing = padding is accepted. Check that the text was copied completely and that nothing such as a quote or URL part was copied along with it.
Why does the decoded result show hex instead of text?
Base64 can carry any bytes, not only text. If the decoded bytes are not valid UTF-8, for example the start of an image file, showing them as text would produce garbage, so the tool shows the bytes in hexadecimal and the byte count instead.
Can this tool encode files or images?
No. This page encodes and decodes text you type or paste. It has no file picker, so to encode a file you need a command-line tool or your own code. Everything runs in your browser and the text is not sent to a server by the tool.
Related converters: the Hex encoder (not sure which to use? see Base64 vs hex: when to use which), the Binary encoder (see also how to convert binary to text and back), the Base32 encoder, the Base58 encoder, the URL encoder and the UUencode tool.