Base64 Encode / Decode
Convert text to Base64 and decode it back in your browser. UTF-8 safe with an optional URL-safe variant — nothing is ever uploaded to a server.
Input
0 lines · 0 chars
Mode
URL-safe
How to use Base64 Encode / Decode
- 1
Choose Encode or Decode
Set the Mode to Encode to turn text into Base64, or Decode to turn a Base64 string back into readable text.
- 2
Enter your input
Type or paste your text or Base64 into the input panel, and optionally turn on URL-safe for the URL- and filename-friendly alphabet.
- 3
Convert
Click Convert to process the input locally in your browser, with full UTF-8 and emoji support.
- 4
Copy or swap
Copy the result, or use Swap to move the output back into the input and flip the mode for a quick round trip.
The Complete Guide to Base64 Encoding
What Base64 actually is
Base64 is a binary-to-text encoding scheme: it represents arbitrary binary data using only 64 printable ASCII characters that survive transmission through systems built for plain text. The standard alphabet, defined in RFC 4648, is the 26 uppercase letters A-Z, the 26 lowercase letters a-z, the ten digits 0-9, and the two symbols + and /. That is 64 symbols, which is exactly enough to represent six bits of data per character, because two to the sixth power is 64.
The name is literal. Just as base 10 uses ten digit symbols and base 16 (hex) uses sixteen, base 64 uses sixty-four. The encoding is completely reversible and lossless: any bytes you encode come back byte-for-byte identical when you decode them, which is the whole point.
Why Base64 exists
Many channels were designed to carry text, not raw bytes, and they mangle anything outside the printable ASCII range. Email is the classic example: the original SMTP standard was a seven-bit protocol that could corrupt or strip the high bit of binary data, so MIME uses Base64 to ship image and file attachments safely. The same problem shows up whenever binary needs to ride inside something textual.
You meet Base64 constantly without noticing. Data URIs embed images directly in HTML and CSS as data:image/png;base64,iVBORw0K... so a small icon needs no separate request. JSON Web Tokens (JWTs) are three Base64url segments joined by dots. HTTP Basic authentication sends Base64 of username:password. Browsers expose it through the built-in btoa and atob functions, and it is the standard way to stuff binary payloads into JSON, XML, or a URL.
How the 3-byte to 4-character mapping works
Base64 processes input three bytes at a time. Three bytes are 24 bits, and 24 divides evenly into four groups of six bits. Each six-bit group is a number from 0 to 63, which becomes one character from the alphabet. So every 3 bytes of input always produce exactly 4 output characters, which is why Base64 inflates data by roughly one third: the encoded form is about 133% the size of the original.
Position in the alphabet is what matters. Index 0 is A, index 25 is Z, index 26 is a, index 51 is z, index 52 is 0, index 61 is 9, index 62 is +, and index 63 is /. To read an encoded string by hand, you map each character back to its index, write that index as six bits, concatenate all the bits, and slice the stream back into eight-bit bytes.
A worked example: encoding "Man"
Take the three letters M, a, n. Their ASCII byte values are 77, 97, and 110, which in binary are 01001101, 01100001, and 01101110. Concatenate those 24 bits into one stream: 010011010110000101101110. Now slice it into four six-bit groups: 010011, 010110, 000101, 101110.
Those groups are the numbers 19, 22, 5, and 46. Looking each up in the alphabet gives T (index 19), W (index 22), F (index 5), and u (index 46). So "Man" encodes to "TWFu" — a clean three-bytes-to-four-characters conversion with no padding needed. Decoding simply runs the steps in reverse.
Padding and the equals sign
Input is not always a multiple of three bytes, so Base64 needs a way to signal the remainder. When one byte is left over, it encodes to two characters followed by two padding marks (==); when two bytes are left over, they encode to three characters followed by one padding mark (=). The padding character carries no data; it only tells the decoder how many real bytes the final group represents.
For example, the single letter "M" (byte 77, binary 01001101) is padded to six bits as 010011 and 010000, giving T and Q, then completed with == to make "TQ==". The word "Ma" (two bytes) encodes to "TWE=" with a single trailing equals sign. Counting the equals signs at the end of any Base64 string tells you whether the original length was a multiple of three.
The URL-safe variant
The standard + and / characters are problematic in places where they already have meaning. A slash splits path segments in a URL, and a plus sign is interpreted as a space in form-encoded query strings, so a normal Base64 value can break when dropped into a link or a filename. The URL-safe alphabet, also from RFC 4648, fixes this by swapping + for - (hyphen) and / for _ (underscore).
Turning on the URL-safe option in this tool produces that variant and also drops the trailing = padding, since equals signs likewise need escaping in URLs. The result slots directly into query parameters, path segments, cookies, and filenames. This is the encoding used by JWTs and many web APIs. Just remember to decode URL-safe input with a URL-safe decoder, because the - and _ characters are not valid in the standard alphabet.
Base64 is encoding, not encryption
This is the single most important and most misunderstood fact about Base64. Encoding obscures data only to the naked eye; it provides zero confidentiality. There is no key and no secret, so anyone can decode a Base64 string instantly using any tool, including this one. Treating Base64 as a way to hide passwords, API keys, or personal data is a serious security mistake.
Base64 solves a transport problem, not a secrecy problem: it makes binary safe to move through text-only channels. If you need actual protection, encrypt the data with a real algorithm such as AES first, and only then Base64-encode the ciphertext if you also need it to travel as text. Encoding and encryption are different jobs.
Common mistakes and practical tips
The most frequent error is character-set confusion. Base64 itself only knows bytes, so before you can encode text you must decide how that text becomes bytes. This tool uses UTF-8, which is why accented letters and emoji round-trip correctly; encoding the same string as a different charset elsewhere yields different Base64. A second common pitfall is whitespace: line breaks inserted by some encoders (MIME wraps at 76 characters) are not part of the data and must be stripped before decoding, though strict decoders may reject them.
Other gotchas include mixing the standard and URL-safe alphabets, forgetting that an unpadded string may need its padding restored before a strict decoder will accept it, and assuming Base64 saves space — it never does, it always grows the payload by about a third. When a decode fails here, check first for a stray space, a missing equals sign, or a - or _ that belongs to the URL-safe alphabet.
Frequently asked questions
What is the difference between Encode and Decode here?
What does the URL-safe option do?
Does it handle emoji and non-English characters?
What happens if I paste invalid Base64 while decoding?
Is my data sent anywhere?
Related tools
Keep going with these handy tools