Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text. UTF-8 safe.

Loading…

All processing runs in your browser — no files or inputs are uploaded to a server.

How to use

Toggle Encode or Decode at the top of the input pane, paste your text, and the result updates live in the output pane. The encoder takes UTF-8 text — Korean, Japanese, emoji all round-trip cleanly. The decoder takes standard Base64 (the A–Z, a–z, 0–9, +, /, = alphabet) and returns the original text.

Use this when you need to embed binary-ish data inside text-only fields: a data URI for an inline image, a payload in a YAML secret, an HTTP Basic Auth header. Everything runs in your browser via the native btoa, atob, TextEncoder, and TextDecoder APIs, so the input never leaves the page.

Examples

Encode a Basic Auth header

Input
alice:s3cret
Output
YWxpY2U6czNjcmV0

HTTP Basic Auth concatenates user:pass and Base64-encodes it. Prefix with "Basic " for the Authorization header value.

Round-trip UTF-8 text

Input
안녕 こんにちは 🌏
Output
7JWI64WV44GT44KT44Gr44Gh44GvIPCfjI8=

Non-ASCII text encodes via UTF-8 first, so each character usually takes 2–4 bytes. The output is longer than the input by roughly 4/3.

Decode a data URI body

Input
SGVsbG8sIHdvcmxkIQ==
Output
Hello, world!

Strip the "data:text/plain;base64," prefix before pasting — this tool decodes the Base64 body only.

FAQ

Why does decoding a JWT segment fail?

JWT uses base64url, a variant that replaces + with - and / with _ and drops the trailing = padding. Standard Base64 cannot read it directly. Either swap the characters back and re-add padding, or use the [JWT Decoder](/en/jwt-decoder/) which handles base64url natively.

Can I encode a binary file (image, PDF) here?

Not directly — this is a text in / text out tool. For a file, drop it into the browser DevTools console and use FileReader.readAsDataURL, or use a dedicated file-to-Base64 converter. The encoding logic is the same; only the input handling differs.

Is Base64 encryption?

No. Base64 is a reversible encoding — anyone can decode it without a key. It exists to fit arbitrary bytes into text-only transport channels (email bodies, JSON strings, URLs), not to hide content. Never use it to protect secrets.

Why does the encoded output end with one or two = signs?

Base64 packs every 3 input bytes into 4 output characters. When the input length is not a multiple of 3, the encoder pads the final group with = so the output is always a multiple of 4 characters. One trailing = means 2 input bytes in the final group; two = means 1.

Does it support line breaks in the Base64 output (PEM / MIME style)?

Decoder side, yes — atob tolerates whitespace, so PEM bodies and MIME-wrapped Base64 decode fine even with embedded line breaks. The encoder produces a single unbroken line. If you need 64-character wrapping, split the output manually or run it through a PEM tool.

Related concepts

Base64 maps every 3 bytes of binary data to 4 ASCII characters drawn from a 64-character alphabet (A–Z, a–z, 0–9, +, /), with = used as padding. The result is roughly 33% larger than the input but contains only characters that survive text-only channels — exactly what was needed when MIME defined it in 1992 for email attachments.

Three variants matter in practice. Standard Base64 (RFC 4648 §4) uses + and /. URL-safe base64url (RFC 4648 §5) substitutes - and _ so the encoded form can sit in a URL or filename without further escaping, and usually drops the = padding — this is what JWT and JWS use. MIME Base64 wraps lines at 76 characters for legacy mail transport. Encoding is not encryption: decoding requires no key and is mechanical. Anything sensitive needs a real cipher, with Base64 only used to ferry the ciphertext through text channels.

Related articles

Related tools