About Base64 Encode

Base64 (RFC 4648) turns arbitrary bytes into a 64-character alphabet — A–Z, a–z, 0–9, + and / — so binary data can travel through channels designed for text: JSON payloads, HTTP headers, data: URLs, XML, email bodies. Every 3 input bytes become 4 output characters, which is why Base64 output is always about 33% larger than its input.

This encoder runs in your browser and handles Unicode correctly: text is first encoded to UTF-8 bytes, then those bytes are Base64-encoded. That two-step detail matters — JavaScript's naive btoa() throws on any character outside Latin-1, which is why 'btoa fails on emoji' is one of the most-hit encoding problems in web development.

How to use Base64 Encode

  1. Enter or paste the text you want to encode in the input area.
  2. Click "Convert" (or press Ctrl+Enter) to get Base64 output.
  3. Copy or download the result.

Example

Input

Hello, World!

Output

SGVsbG8sIFdvcmxkIQ==

How Base64 actually works

The encoder takes the input bytes 3 at a time (24 bits), splits them into four 6-bit groups, and maps each group to one character of the alphabet. When the input length is not a multiple of 3, the last block is padded: one leftover byte produces two characters plus '==', two leftover bytes produce three characters plus '='. That is all the trailing equals signs mean — how many bytes the final block was short.

Because the mapping is fixed and reversible, Base64 is pure encoding. It provides zero secrecy: anyone can decode it instantly. If you can read this sentence, you can reverse SGVsbG8=. Use encryption (AES-GCM) for confidentiality and Base64 only for transport.

Standard Base64 vs Base64url — a bug factory

The standard alphabet uses + and /, both of which are meaningful inside URLs (+ decodes to a space in query strings; / is a path separator). RFC 4648 §5 therefore defines base64url: - replaces +, _ replaces /, and padding is usually dropped. JWTs, OAuth state values, and most API tokens use base64url.

Mixing the two variants is a classic interoperability bug: a standard decoder chokes on - and _, and a URL will silently corrupt + into a space. If your encoded value is destined for a URL, query parameter, cookie, or JWT, use the base64url variant or additionally URL-encode the output.

Where you meet Base64 in practice

  • data: URLs — inlining small images or fonts into CSS/HTML: data:image/png;base64,iVBOR...
  • HTTP Basic auth — the Authorization header carries base64(user:password). Encoded, not encrypted: without TLS the credentials are effectively plaintext.
  • JWTs — header and payload are base64url-encoded JSON; you can decode and read them without any key.
  • Binary in JSON — file uploads, images, or protobuf blobs embedded in JSON APIs.
  • Email attachments (MIME) and PEM certificate files (the blocks between BEGIN/END markers are Base64).

Common errors and how to fix them

btoa() throws "InvalidCharacterError: The string to be encoded contains characters outside of the Latin1 range"

Cause: btoa operates on bytes 0–255; any emoji, Thai, Chinese, or accented character breaks it.

Fix: Encode to UTF-8 first: btoa(String.fromCharCode(...new TextEncoder().encode(str))) — or use this tool, which does it for you.

Decoded output is mojibake (â†etc.) on the other side

Cause: The producer encoded UTF-8 bytes but the consumer decoded them as Latin-1 (or vice versa).

Fix: Agree on UTF-8 on both sides. In JS decoding: new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0))).

Base64 breaks when passed in a URL

Cause: + becomes a space in query-string parsing, and / can break path routing.

Fix: Use base64url (replace + with -, / with _, strip =), or wrap the value in encodeURIComponent().

Output has line breaks that the consumer rejects

Cause: MIME Base64 (RFC 2045) wraps lines at 76 chars; some encoders add breaks, some decoders refuse them.

Fix: This tool outputs a single unbroken string. If input from elsewhere has breaks, strip whitespace before decoding.

Tips and best practices

  • Size math: Base64 output ≈ ceil(n/3)×4 characters. A 1 MB file becomes ~1.37 MB — think twice before inlining large assets into JSON or CSS.
  • The = padding is often optional in practice (JWTs drop it), but some strict decoders require it. When in doubt, keep padding for standard Base64 and drop it for base64url.
  • Base64 in an Authorization: Basic header is not security. Anything sensitive needs TLS in transit and never client-side 'encoding' as protection.
  • For hashing or signatures, encode the raw bytes — encoding a hex string of the hash instead of the bytes is a common interop bug between languages.

Frequently asked questions

Is Base64 encryption?
No. It is a reversible mapping with no key. Anyone can decode it instantly. Use it for transport of binary data through text channels, never for secrecy.
Why does the output end with = or ==?
Padding. Base64 processes input in 3-byte blocks producing 4 characters; when the final block has 1 or 2 bytes, it is padded with == or = respectively. The padding tells the decoder the original length.
How does this tool handle emoji and non-Latin text?
Text is first converted to UTF-8 bytes, then encoded. '你好' → 5L2g5aW9. This avoids the browser btoa() Latin-1 limitation entirely.
What is the difference between Base64 and Base64url?
Two characters and the padding: base64url uses - and _ instead of + and /, and typically drops =. URLs, filenames, JWTs, and OAuth values need base64url; everything else usually expects standard Base64.
Does Base64 compress data?
The opposite — it inflates data by ~33%. If size matters, compress first (gzip), then Base64 the compressed bytes.
Is my text sent to a server?
No. Encoding happens entirely in your browser.

Embed this tool

Add Base64 Encode to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.

Related tools