Skip to content

Base64 Encoder / Decoder

Base64 output

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

Base64 is a way to represent arbitrary bytes as a string of 64 printable ASCII characters. This tool encodes plain text (including emoji and CJK characters) to Base64, and decodes Base64 strings back to text.

How Base64 encoding works

Every three bytes of input (24 bits) are split into four 6-bit groups. Each 6-bit group maps to one character in a 64-character alphabet: A–Z (values 0–25), a–z (26–51), 0–9 (52–61), and two more characters that depend on the variant. Standard Base64 uses + (62) and / (63). URL-safe Base64 (also called Base64url) uses - (62) and _ (63) instead, and drops the trailing = padding.

When the input length is not a multiple of three, the final group is padded. One trailing = means one padding byte was added; == means two.

The encoding is completely reversible: given a valid Base64 string, anyone can reconstruct the original bytes without any key or password. Base64 is an encoding scheme, not encryption.

Where Base64 is used

Data URIs — browsers accept data:image/png;base64,<encoded> as an image source, so you can embed a small image directly in an HTML file or CSS rule without a separate HTTP request.

Email attachments — MIME (Multipurpose Internet Mail Extensions) encodes binary attachments as Base64 so they can travel through email systems that were originally designed for 7-bit ASCII text.

JSON Web Tokens — a JWT consists of three parts separated by dots: header.payload.signature. The header and payload are JSON objects encoded with URL-safe Base64 (no padding). The signature is also Base64url. Decoding a JWT’s first two parts reveals its claims; verifying the signature requires the secret key.

HTTP Basic authentication — the Authorization: Basic <credentials> header carries username:password encoded as standard Base64. The colon separator is part of the encoded value.

Example: encoding “Hello, World!”

Input: Hello, World! (13 bytes, UTF-8)

Standard Base64: SGVsbG8sIFdvcmxkIQ==

URL-safe Base64: SGVsbG8sIFdvcmxkIQ (same characters, trailing == stripped)

For strings that happen not to use + or /, the standard and URL-safe outputs look identical — the difference only appears when those characters are needed.

Unicode and emoji

Standard btoa in browsers only handles Latin-1 (byte values 0–255). To encode full Unicode text, this tool converts the string to UTF-8 bytes first using TextEncoder, then applies the Base64 algorithm to those bytes. Decoding reverses the process: decode Base64 to bytes, then interpret them as UTF-8 via TextDecoder. This means any Unicode character — including emoji like 😀 and CJK characters like 日本語 — round-trips correctly.

Common mistakes

Mixing up standard and URL-safe: if you encode with URL-safe and then try to decode with a tool that expects standard Base64, the - and _ characters will fail. If your Base64 looks right but throws an error, check which variant was used.

Assuming Base64 is a security measure: it is not. A Base64-encoded string is trivially decoded by anyone who sees it. If you are storing a password or secret in Base64, it is not protected.

Forgetting that encoding expands the size: Base64 output is approximately 33% larger than the input (every 3 bytes become 4 characters). For large binary files this overhead can be significant; Base64 is not a compression format.

For percent-escaping a URL instead (different encoding, different purpose), use the URL encoder / decoder. For the base64url slice inside a JSON Web Token, the JWT decoder handles the full three-segment split.

Frequently asked questions

What is Base64 used for?

Base64 turns arbitrary binary data into a string of printable ASCII characters. You see it in email attachments (MIME encoding), data URIs that embed images directly in HTML or CSS, JSON Web Tokens (the header and payload are Base64url-encoded), HTTP Basic authentication headers (username:password is Base64-encoded before being placed in the Authorization header), and anywhere a protocol requires text but the data is binary.

When do I need URL-safe Base64 instead of standard?

Standard Base64 uses + and / as the 62nd and 63rd characters. Both have special meaning in URLs — + is treated as a space in query strings, and / is a path separator. URL-safe Base64 (sometimes called Base64url) replaces + with - and / with _, and drops the = padding. Use it when the Base64 value will appear in a URL, a filename, or a cookie value. JWTs always use URL-safe Base64 for this reason.

Is Base64 a form of encryption?

No. Base64 is an encoding scheme, not encryption. Anyone who sees a Base64 string can decode it instantly — no key, no password, no effort. It exists to represent binary data as printable ASCII, not to hide information. If you need to protect data, use actual encryption (AES, RSA) or a cryptographic hash. Encoding something as Base64 and assuming it is secure is a common and dangerous mistake.

Why does Base64 output end with = or ==?

Base64 groups input bytes into sets of three (24 bits), then splits each group into four 6-bit values. When the input is not a multiple of three bytes, the last group is padded with zero bits and the output is padded with = characters to keep the total length a multiple of four. One = means one padding byte was added; == means two. URL-safe Base64 strips this padding since the length can be inferred.