Developer Tool

Base64 Encoder / Decoder

Encode or decode Base64 text and files — URL-safe mode, line wrapping, real-time validation. 100% in-browser.

Mode

Direction

Plain Text

0 chars · 0 B

Swap

Base64 OutputWaiting

Encoded output will appear here

Options

URL-safe Base64 (RFC 4648 §5) — replaces + → - and / → _

Wrap lines every 76 characters (MIME standard)

Tip: Use URL-safe mode when embedding Base64 in URLs, JWT tokens, or filenames. Use line-wrap for PEM/MIME compatibility.

Common use cases

🔐

API authentication

HTTP Basic Auth encodes credentials as Base64. JWT tokens use URL-safe Base64 for header and payload.

📧

Email attachments (MIME)

MIME email encodes binary attachments in Base64 with 76-character line-wrapping so mail servers handle them safely.

🖼️

Inline images & data URIs

Embed images directly in HTML or CSS as data:image/png;base64,… to eliminate extra network requests.

🔗

URL-safe tokens

Store binary blobs (UUIDs, checksums) in URLs or cookies using URL-safe Base64 — no percent-encoding needed.

Common questions

Is Base64 encryption?

No. Base64 is an encoding scheme, not encryption. It transforms binary data into ASCII text so it can be safely transported over text-based protocols. Anyone can decode it — there's no key or secret involved.

Why does encoded text end with = or ==?

Base64 encodes 3 bytes at a time into 4 characters. If the input isn't divisible by 3, padding characters (=) are added to complete the group. URL-safe mode strips them since padding is optional in most contexts.

What's the size overhead?

Base64 encoding increases size by roughly 33% — every 3 bytes become 4 characters. Line-wrapping adds a small extra overhead. This is the expected trade-off for safe text transport.

Is my data safe using this tool?

Absolutely. Everything runs inside your browser using native JavaScript APIs (btoa, atob, FileReader). No data is ever sent to a server.

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

Standard Base64 uses + and / characters which have special meanings in URLs. URL-safe Base64 (RFC 4648 §5) replaces them with - and _ so the output can be used in URLs, filenames, and HTTP headers without escaping.

What Base64 Is Actually For

Legitimate jobs for Base64

Base64 exists to carry binary data through channels built for text. The places you'll genuinely meet it:

Where	What's encoded	Why
Data URIs in HTML/CSS	Small images, fonts	Saves an HTTP request
Email attachments (MIME)	Every attachment you've ever sent	Email transport is text-only
JWT tokens	Header and payload JSON	URL-safe transport of structured data
API payloads	Files inside JSON	JSON can't hold raw binary
Basic HTTP auth	username:password	Header-friendly format — not protection

Encoding is not encryption

Base64 has no key and no secret — anyone can decode it instantly, which is exactly what this page does. Treating it as protection is a real and recurring security mistake: credentials “hidden” in Base64 are plaintext with extra steps. It also grows data by ~33%, so it's not compression either. It is purely a transport format: binary in, safe ASCII out, reversible by design.

Debugging with a decoder

The daily developer use: an opaque string in a config file, header or database column — decode it and see what it really holds. Strings with dots in them are usually JWTs, better inspected with the JWT decoder, which splits all three parts. Encoding images for CSS is the image to Base64 tool's job, and URL-mangled strings (%20 everywhere) want the URL encoder/decoder instead — a different encoding for a different problem.