Skip to main content

Base64 Text Encoder

What it does

The Base64 Text Encoder converts text to and from base64 with correct UTF-8 handling — emoji, accented characters, CJK scripts all round-trip cleanly. Two variants are supported: Standard (RFC 4648, uses +, /, and = padding) and URL-safe (RFC 4648 §5, uses -, _, and drops padding). Edit either pane and the other updates live.

Common situations

You’re embedding a credential in a configuration file. The credential contains special characters that break YAML or JSON; encoding it as base64 produces a string that travels safely through any text-based config format.

You’re decoding a string from a log entry or HTTP header to investigate what was actually sent. Cookies, session tokens, error responses, debug output — base64 is sprinkled throughout production systems. Decoding reveals the underlying data, which is the start of most “what is this token actually saying?” investigations.

You’re working with JWTs and need to manually decode the URL-safe base64 segments. The dedicated JWT Decoder handles complete tokens; this tool is for working with individual segments or URL-safe base64 in other contexts.

You’re transmitting binary-ish text through a system that mishandles non-ASCII. Multibyte UTF-8 strings sometimes lose data passing through legacy gateways or message queues. Encoding to base64 first produces ASCII output that survives any text channel.

You’re producing test fixtures that include binary-ish content. Real binary data (images, files) cannot live cleanly in JSON or YAML; base64 is the universal convention for “binary data inside a text format”.

What you need to know

The browser’s built-in btoa and atob work in Latin-1, which means they fail loudly on multi-byte characters — btoa('café') throws. The fix is to encode the text as UTF-8 bytes first using TextEncoder, base64-encode the bytes, and on the decode side reverse: atob to bytes, then TextDecoder to a string. The tool does this transparently so you can paste any Unicode text without thinking about it.

URL-safe base64 swaps the two characters that have special meaning in URLs (+ becomes -, / becomes _) and drops the trailing = padding (which means “this is the end” and is not strictly needed for decoding). Both variants represent the same bytes — they are interchangeable as long as the encoder and decoder agree on which one is in use.

Standard vs URL-safe: Standard appears in JSON fields, HTTP bodies, database columns. URL-safe appears in JWTs, OAuth flows, and URL paths. The wrong variant in the wrong context produces decoding errors.

Padding (= characters at the end) makes the string length a multiple of 4. Standard base64 always pads; URL-safe usually doesn’t. Decoders should handle both, but some strict implementations reject missing padding — adding it back manually fixes those cases.

Whitespace handling in pasted base64 is forgiving in this tool — newlines, tabs, and stray spaces are stripped automatically. RFC 4648 allows line breaks at column 76 for readability; some encoders insert them, some don’t. The decoder handles both.

Base64 is encoding, not encryption. Anyone can decode base64 without a key. Putting “secret” data in base64 protects it from absolutely nothing. For privacy, you need actual encryption (AES, ChaCha, etc.) — base64 is just a textual representation of bytes.

Round-tripping is lossless for binary data. Whatever you encode comes back out byte-identical. Where round-trips break is encoding-confusion: encoding Latin-1, decoding UTF-8 produces garbage. The tool consistently uses UTF-8, so round-trips through it are clean.

The size penalty is roughly 33% — every three bytes of input become four characters of output, plus padding overhead. A 100-byte string becomes ~136 characters of base64. This matters for storage, bandwidth, and readability of inlined data.

Frequently asked questions

What is base64 encoding?

A way to represent binary data using only 64 ASCII characters (A–Z, a–z, 0–9, plus two extra). Useful when binary data needs to travel through text-only channels (JSON, email, URLs, config files).

What’s the difference between base64 and URL-safe base64?

Standard base64 uses +, /, and = for padding. URL-safe replaces + with - and / with _, and usually drops padding. Both encode identical bytes — the difference is which characters they use.

Why does btoa fail on emoji?

btoa works on Latin-1 (single-byte characters). Emoji are multi-byte UTF-8. To encode emoji, encode UTF-8 first via TextEncoder, then base64-encode the bytes. The tool does this automatically.

Is base64 secure?

No — base64 is encoding, not encryption. Anyone can decode it without a key. For security, use actual encryption (AES, etc.). Base64 just makes binary data text-safe for transport.

How do I encode binary data?

Read it as bytes (FileReader for files, fetch for URLs), then base64-encode the bytes. The tool here handles text only; for binary files, use a CLI tool (base64 file > out.b64) or a small custom page.

What’s the size overhead of base64?

About 33%. Three bytes of binary become four characters of base64. Plus padding (up to 2 trailing =). A 1KB file becomes ~1.36KB of base64.

Does padding matter?

Strict decoders require it. Lenient ones accept missing padding (URL-safe base64 typically drops it). When in doubt, add padding to make the string length a multiple of 4 — this works for both strict and lenient decoders.

Can I base64 a URL?

Yes — same encoding works on any string. URL-safe variant is convenient when the encoded result will itself live in a URL.

Common problems

Problem: Base64-encoded emoji decodes to garbage characters.

You encoded as Latin-1 instead of UTF-8. Browser’s btoa is Latin-1; fix by encoding the string as UTF-8 bytes first, then base64. The tool here uses UTF-8 by default.

Problem: Base64 string fails to decode with “invalid character”.

Either invalid characters mixed in (whitespace is fine, other punctuation is not), or wrong variant. URL-safe base64 in a standard decoder fails because - and _ aren’t valid standard characters. Switch variants or normalise the input.

Problem: Base64 string fails to decode with “wrong length”.

Missing padding. Standard base64 must be a multiple of 4 characters; pad with = until it is. URL-safe usually drops padding but some decoders still require it.

Problem: Encoded result is much larger than expected.

Base64 has ~33% overhead by design. Plus, if the source has many newlines or whitespace, those count toward input size. For smaller output, compress the source first (e.g. gzip, then base64) or use a more efficient encoding (binary protocols, MessagePack).

Problem: A JWT’s signature segment fails to decode through this tool.

JWT signatures are URL-safe base64 of binary signature bytes — the decoded result is binary, not text. Trying to display binary as text produces garbage. Use the JWT Decoder for the structured decoding, or accept that signature segments don’t decode to readable text.

Quick guides

JavaScript (text): btoa(unescape(encodeURIComponent(str))) for legacy UTF-8-safe encoding. Modern: encode via TextEncoder, then base64-encode the bytes manually. Or use a library — js-base64 package handles all the edge cases.

Python: base64.b64encode(s.encode('utf-8')).decode('ascii') for standard. base64.urlsafe_b64encode(s.encode('utf-8')).decode('ascii').rstrip('=') for URL-safe without padding.

Shell: echo -n "text" | base64 for standard. echo -n "text" | base64 | tr '+/' '-_' | tr -d '=' for URL-safe.

Tips

  • Standard base64 is right when the encoded value lives in a JSON field, a HTTP body, or a database column. URL-safe is right when it lives in a URL path or query string, or inside a JWT.
  • Whitespace and line breaks in pasted base64 are stripped automatically. Some tools wrap base64 at 76 characters per RFC; the decoder handles either form.
  • Padding is sometimes truncated in the wild. Standard base64 strings should be a multiple of 4 characters; missing padding is usually = characters that need restoring.
  • Base64 is encoding, not encryption. Anyone can decode anything in base64 — there is no key. If the goal is privacy, base64 alone is the wrong tool.
  • Round-tripping through base64 is lossless for binary data. If your decoded text differs from the original, the encoder probably ran on the wrong byte representation (Latin-1 instead of UTF-8 is the classic).
  • For very large data, base64 is wasteful. Consider whether your transport actually requires text — if not, send binary directly.

Related tools in this suite

The natural pairing is the URL Encoder — both produce safer string representations for transport, and both come up in the same workflows. The JWT Decoder is the higher-level partner — it handles the URL-safe base64 internally so you do not need this tool unless inspecting individual segments.

Take it further

Base64 is the right tool for short, transient encoding needs — config values, API tokens, embedded credentials. For larger payloads or anything performance-sensitive, the encoding overhead and CPU cost add up. The services we deliver include the architectural conversations that decide where to use base64 and where to choose binary transport, signed URLs, or content-addressed storage instead.