Base64 encoder / decoder
Encode text to Base64 or decode Base64 back to readable text. Supports UTF-8 and URL-safe Base64. Instant results.
Ctrl + L clear | Ctrl + Shift + C copy output
About Base64 encoding
Base64 is a binary-to-text encoding scheme that represents any sequence of bytes using only 64 printable ASCII characters — the letters A–Z and a–z, the digits 0–9, and two symbols. It exists because many systems, especially older text-based protocols like email, were built to carry only readable 7-bit ASCII characters and would corrupt or reject raw binary data such as images or encrypted keys. Base64 sidesteps that limitation by repacking every 3 bytes of binary data into 4 text characters, so the result travels safely through systems that only understand text, at the cost of being about a third larger than the original data.
History of Base64 encoding
Base64-style encoding traces back to Privacy-Enhanced Mail (PEM), described in RFC 989 in 1987, which needed a way to carry encrypted binary data — keys, signatures, certificates — through email systems built only for plain ASCII text. The specific 64-character alphabet used today was standardized as part of MIME (Multipurpose Internet Mail Extensions) by Nathaniel Borenstein and Ned Freed, first published as RFC 1521 in 1993 and refined in RFC 2045 in 1996, so that email attachments such as images and documents could travel safely over text-only mail servers. The name "Base64" simply describes its 64-symbol alphabet, the same naming convention behind Base16 (hexadecimal) and Base32 encoding.
How Base64 encoding works
Base64 groups input data into chunks of 3 bytes, which is exactly 24 bits. Each chunk is split into four 6-bit groups, and since 2 to the power of 6 equals 64, each 6-bit group maps directly onto one of the 64 alphabet characters. When the input length is not a multiple of 3 bytes, the final chunk is padded with zero bits and the output is padded with one or two equals signs to keep the result a multiple of 4 characters. This fixed, reversible mapping is what makes Base64 fast to encode and decode without needing to understand the content of the data at all.
What Base64 encoding is used for
Base64 is everywhere in modern web development. Data URIs embed small images and fonts directly inside CSS or HTML using Base64, avoiding an extra network request. JSON Web Tokens (JWTs) use URL-safe Base64 to encode their header and payload segments so they can be passed safely in URLs and HTTP headers. Email attachments are still transmitted as Base64 under the MIME standard, HTTP Basic Authentication encodes the username and password pair in Base64 before sending it in a request header, and APIs frequently Base64-encode binary files — images, PDFs, certificates — so they fit inside text-only JSON or XML payloads.
Frequently asked questions
Why is my Base64-encoded string about 33% longer than the original text?
Base64 encodes every 3 bytes of input as 4 output characters, because each output character can only represent 6 bits of data and 3 bytes is 24 bits — exactly four 6-bit groups. That 3-to-4 ratio is a fixed 33% size increase before padding is even considered. It is the unavoidable cost of representing arbitrary binary data using only 64 printable ASCII characters, which is why Base64 is used for compatibility with text-only systems rather than for compression.
What is the difference between standard Base64 and URL-safe Base64?
They use almost the same 64-character alphabet but swap two symbols. Standard Base64 uses + and / for the values 62 and 63, which are both reserved characters inside URLs and file paths — a + can be read as a space and a / as a path separator. URL-safe Base64 replaces them with - and _, and the trailing = padding is usually stripped, so the result can be dropped directly into a URL, filename or cookie without further escaping. JSON Web Tokens and many web APIs use the URL-safe variant for exactly this reason.
Why do Base64 strings end with one or two equals signs?
The equals sign is padding, added when the input length is not a multiple of 3 bytes. One trailing byte produces two padding characters and two trailing bytes produce one, keeping the output length a multiple of 4 as the format requires. Padding carries no data — it only signals how many of the final 4 characters are meaningful — which is why URL-safe Base64 and some other implementations omit it entirely and recover the original length from context instead.
Is Base64 encoding a form of encryption?
No. Base64 is an encoding, not encryption — it has no secret key, and anyone can decode it instantly using this tool or a single line of code in any programming language. It is sometimes mistaken for security because it turns readable text into unfamiliar-looking characters, but that is only a side effect of representing binary data as text. Passwords, tokens or personal data should never be considered protected just because they are Base64-encoded; use real encryption if confidentiality actually matters.
Why does decoding produce an error or garbled text instead of my original message?
The most common cause is pasting an incomplete string — a Base64 string cut off mid-copy loses the trailing padding and characters needed to reconstruct the original bytes. Mixing standard and URL-safe characters, stray whitespace inside the string, or accidentally including surrounding quotes copied from a JSON file can also break decoding. If the string decodes without error but the text looks garbled, the original bytes likely were not UTF-8 text at all — they may be an image, a compressed file or another binary format that this tool renders as text with replacement characters.