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