Encoding

Base64 Encoder & Decoder

Encode any text to Base64, or decode Base64 back to text. URL-safe variant available. All processing happens locally in your browser.

URL-safe (- and _ instead of + and /) Strip padding (=)

About Base64 encoding

Encode arbitrary text or binary data into Base64 — and decode it back. Standard and URL-safe variants supported. Everything runs locally in your browser; nothing is uploaded.

What Base64 is

Base64 is a binary-to-text encoding. It converts arbitrary bytes — an image, a binary blob, a string of text — into a sequence of 64 printable ASCII characters: A-Z, a-z, 0-9, plus the characters + and /. The result is safe to paste into JSON, store in a database column, send in an email body, or include inline in HTML and CSS.

Three things Base64 is not: encryption, compression, or hashing. The transformation is fully reversible by anyone — encoding makes data portable, not secret.

Why use Base64 at all

Three real-world reasons:

Embedding binary in text formats. Email (RFC 5321), JSON, XML, and HTML can only carry printable text reliably. To put a small image inside an HTML <img> tag without a separate file request, encode it as Base64 and use a data: URL.
Authorization headers. HTTP Basic Auth uses Base64 to combine a username and password into a single header value. The header isn't encrypted (TLS handles that), but Base64 keeps the colon-separated value safely transmissible.
API keys and tokens. Many tokens (JWTs, signed cookies, request signatures) use Base64 to encode binary signature bytes into URL-safe strings.

The URL-safe variant

Standard Base64 produces +, /, and = characters. + in a URL means "space." / is a path separator. = is a query-string symbol. None of them survive round-trips through URL parsing without percent-encoding.

The fix is Base64URL — a variant defined in RFC 4648 §5 that swaps + for - and / for _. The padding (=) is sometimes also stripped. Toggle "URL-safe" in the encoder when the result will travel through URLs, JWT segments, or filenames.

Common pitfalls

Mixing variants. Decoding standard Base64 with a URL-safe decoder (or vice versa) silently produces wrong bytes. Pick one and stay consistent across encode/decode.
Encoding text in the wrong charset. "naïve" encoded as Latin-1 and decoded as UTF-8 produces garbage. Encode and decode in the same character set — default to UTF-8 unless you have a reason not to.
Whitespace in input. Some implementations reject Base64 input that contains line breaks; others tolerate it. The TextKit decoder auto-strips whitespace before decoding.
Missing padding. Strictly compliant Base64 always pads to a multiple of 4 characters with =. Some sources strip it; some decoders require it. The TextKit decoder auto-pads if needed.

Base64 vs other encodings

Encoding	Output alphabet	Size overhead	Use case
Base64	64 chars	~33%	Email, JSON embedding, generic binary→text
Base64URL	64 chars (URL-safe)	~33%	JWTs, URLs, filenames
Hex	16 chars	~100%	Hashes, low-level debugging
Percent-encoding	variable	0-200%	URL components
Base32	32 chars	~60%	Filenames on case-insensitive systems
Base85 (ASCII85)	85 chars	~25%	PostScript, PDF embedded data

How the tool works

The encoder reads your input as UTF-8 bytes (the standard for any text in 2026), then converts to the chosen Base64 variant — standard or URL-safe. The decoder reverses the process, with auto-padding and whitespace tolerance to handle real-world Base64 strings that may have been wrapped or stripped.

Everything runs locally. The text never leaves your browser — useful for sensitive data, internal IDs, or anything covered by an NDA.

Local-only encoding. Both encode and decode happen entirely in your browser. Nothing is uploaded, logged, or transmitted.

Workflow tips

Quick credential encode. For HTTP Basic Auth, paste username:password and copy the Base64 output. Prefix with Basic in the Authorization header.
Inspect a JWT. JWTs are three Base64URL segments separated by dots. Paste the middle segment to see the payload (claims) in clear text.
Decode an unknown blob. Got a string of A-Za-z0-9+/= characters from a log or a config file? Decode it to see if it's text, JSON, or binary garbage.
Inline a tiny image. Encode a small (under ~5KB) PNG to Base64, paste into a data:image/png;base64,... URL inside an <img src> attribute. Avoids a separate HTTP request.

The size penalty

Every 3 input bytes become 4 output characters. The output is roughly 4/3 (33%) larger than the input — plus the padding (=) at the end and any whitespace some implementations add to wrap long output. For small inputs the overhead is invisible; for large files (above ~100KB) it starts to matter and you should prefer real binary transport over Base64-in-text where possible.

Frequently asked questions

Is Base64 encryption?

No. Base64 is encoding, not encryption. It converts binary data to a printable ASCII representation, but anyone can decode it. Don't use it to hide secrets.

What's the difference between standard and URL-safe Base64?

Standard Base64 uses '+', '/', and '=' characters. URL-safe Base64 replaces '+' with '-' and '/' with '_' so the result can travel safely in URLs without percent-encoding. The '=' padding is sometimes omitted in URL-safe variants.

Why does my decoded text contain weird characters?

Base64 is a wrapper around bytes — not text. If the original input was binary (an image, a compressed blob), decoding produces those raw bytes. To preserve text encoding, both encode and decode in the same character set (UTF-8 by default).

How big does Base64 make my data?

About 33% larger. Every 3 bytes of input becomes 4 bytes of output, plus padding. A 1MB image becomes ~1.34MB as Base64.

Can I decode a Base64 string without padding?

Yes — most decoders accept missing padding. The TextKit Base64 decoder auto-pads if needed before decoding.

Is Base64 the same as Base64URL or Base64URL-safe?

Base64URL and URL-safe Base64 are the same thing — the variant with '-' and '_' instead of '+' and '/'. Toggle the URL-safe option in the encoder to produce it.

Tool