Base64 Encoder / Decoder
Encode text or files to Base64 and decode Base64 strings.
Base64 Is Everywhere — and Frequently Misunderstood
If you have ever looked at an HTTP Authorization header, a JWT token, an email MIME attachment, or a CSS data URI, you have encountered Base64. It is one of the most widely used encoding schemes on the internet, and it is also one of the most commonly confused with encryption. The confusion is not trivial — treating encoding as security has caused real data exposures.
Why Base64 Exists
Many text-based protocols and formats — email (SMTP), JSON, XML, HTTP headers — were designed to carry text, not arbitrary binary data. When you need to embed binary data (an image, a cryptographic key, a compiled binary) inside a text-based format, you need a way to represent binary bytes using only printable text characters.
Base64 solves this by mapping every 3 bytes of binary input (24 bits) to 4 printable ASCII characters (6 bits each). The output uses only the characters A–Z, a–z, 0–9, +, and / — all safe to transmit through systems that may corrupt or misinterpret binary data. The tradeoff is a 33% size increase: every 3 bytes of input becomes 4 characters of output.
Base64 Is Not Encryption
This point cannot be overstated: Base64 is trivially reversible by anyone. There is no key, no secret, and no security. A Base64-encoded string is decoded in milliseconds. Storing a password as Base64 provides exactly zero protection compared to storing it in plaintext — both are equally exposed to anyone who reads the value.
Base64 is for encoding (changing the representation of data) not encrypting (protecting data from unauthorised access). Use AES encryption for confidentiality. Use Base64 for compatibility.
Where You Will Encounter Base64 in Practice
- HTTP Basic Authentication: The
Authorization: Basicheader containsusername:passwordencoded as Base64. This is why HTTPS is essential for Basic Auth — without TLS, the credentials are trivially decoded from the header. - JSON Web Tokens (JWTs): The header and payload sections of a JWT are Base64url-encoded (a variant using
-and_instead of+and/for URL safety). Anyone can decode the payload and read its contents — JWTs are not encrypted by default, only signed. - Data URIs:
src="data:image/png;base64,iVBOR..."embeds an image directly in HTML or CSS without a separate HTTP request. - Email attachments: MIME encodes attachments as Base64 so binary files can travel through SMTP, which was designed for 7-bit ASCII text.
- API credentials and secrets: Many APIs deliver secrets as Base64-encoded strings for convenient copy-paste, not for security.
The Padding Characters (= and ==)
Base64 works in 3-byte input chunks. If the input length is not a multiple of 3, the last chunk is padded with one or two = characters to maintain the 4-character output alignment. One = means the last chunk had 2 bytes of real data; two == means the last chunk had 1 byte. Some systems use "unpadded" Base64 and omit the padding — both forms are valid if both encoder and decoder agree.
// faq
Is Base64 a form of encryption? +
No. Base64 is encoding — it changes the representation of data but provides zero confidentiality. Anyone who sees a Base64 string can decode it instantly with no key required. Never use Base64 to protect sensitive data. If you need to protect data, use actual encryption (AES for symmetric, RSA or ECDSA for asymmetric) not encoding.
What is the difference between Base64 and Base64url? +
Standard Base64 uses + and / as the 62nd and 63rd characters. These characters have special meaning in URLs (+ is a space in form data, / is a path separator), so Base64url replaces them with - and _ respectively, making the output safe to include in URL query parameters without percent-encoding. JWTs use Base64url. When decoding a JWT payload, make sure you are using a Base64url decoder, not standard Base64.
Why does my Base64 string end with = or ==? +
Base64 encodes 3 bytes at a time, producing 4 characters per group. If the input length is not divisible by 3, padding characters (=) are appended. One = means the input had 2 bytes in the final group; two == means the input had 1 byte. Some implementations omit padding (unpadded Base64) — if you are seeing a decoding error, check whether you need to add the padding characters back.
Can I encode images or binary files with this tool? +
This tool encodes and decodes text input as UTF-8 bytes converted to Base64. For encoding binary files (images, PDFs, executables) you need to provide the file directly, not paste text. Binary files contain byte sequences that are not valid UTF-8 text, so pasting them into a text field will corrupt the data before encoding. Use a file-to-Base64 converter for binary files.