Base64 Encoder / Decoder.
Convert text or binary files to Base64, or decode Base64 back to text and binary. Supports standard, URL-safe, MIME formats, and multiple character encodings.
Technical Specifications
What is Base64?
Base64 encodes binary data as 64 printable ASCII characters (A–Z, a–z, 0–9, +, /).
Every 3 input bytes become 4 Base64 characters — a 33% size increase. Padding
(=) aligns output to a 4-character boundary.
URL-safe Base64
Standard Base64 uses + and / which must be percent-encoded
in URLs. RFC 4648 §5 (base64url) substitutes them with - and
_ — URL-safe without escaping. Used in JWTs and web APIs.
MIME Format
RFC 2045 (MIME) requires a CRLF line break every 76 characters for email
compatibility. Some MIME parsers reject Base64 without line breaks. Use MIME for email
attachments; Standard for data URIs, JWTs, and APIs.
Character Sets
UTF-8 supports all Unicode in 1–4 bytes per character. ISO-8859-1 (Latin-1) encodes Western European characters in exactly 1 byte. ASCII covers only 0–127. Always match the encoding used for encoding when decoding.
When is Base64 used?
Base64 is used whenever binary data must travel through a text-only channel. Common uses include embedding images in HTML or CSS as data URIs, encoding binary email attachments (MIME), transmitting binary payloads in JSON or XML, storing credentials in HTTP Basic Authentication headers, and representing cryptographic keys and tokens (e.g. JWT).
Standard vs URL-safe Base64
Standard Base64 (RFC 4648 §4) uses + and / as its 62nd and
63rd characters. In URLs these must be percent-encoded, making the string longer and
awkward in query parameters. URL-safe Base64 (RFC 4648 §5) replaces them with
- and _, which are natively safe in URLs. JSON Web Tokens (JWT)
use URL-safe Base64 without padding.
Why does character encoding matter?
Before encoding text to Base64, the text must be converted to bytes. The character set chosen determines that conversion. UTF-8 is the safest universal choice. Latin-1 is compact for Western European text. A mismatch between the encoding used when encoding and when decoding will produce garbled output. Always use the same encoding on both ends.
Common Use Cases
- Data URIs: Embed images or fonts directly in HTML or CSS — no separate HTTP request needed. Useful for small icons and inline SVG backgrounds.
- Email attachments (MIME): RFC 2045 requires MIME-encoded Base64 for binary attachments. Line breaks every 76 characters keep older mail servers compatible.
- API payloads: REST and GraphQL APIs that exchange binary blobs — images, PDFs, certificates — embed them as Base64 strings inside JSON.
- JSON Web Tokens: JWT header and payload segments are URL-safe Base64 encoded (no padding), allowing tokens to appear safely in Authorization headers and URLs.
- HTTP Basic Auth: Credentials are encoded as
username:passwordin Base64 — not encrypted, just encoded. Always combine with HTTPS.
Frequently Asked Questions
- What is Base64 encoding used for?
- Base64 encodes binary data as printable ASCII so it can travel through text-only channels — data URIs in HTML/CSS, MIME email attachments, JSON API payloads containing binary blobs, and cryptographic tokens like JWTs.
- What is the difference between standard and URL-safe Base64?
- Standard Base64 uses
+and/, which must be percent-encoded in URLs. URL-safe Base64 (RFC 4648 §5) replaces them with-and_— safe in query parameters without escaping. JWTs always use URL-safe Base64 without padding. - Why does Base64 output contain = padding characters?
- Base64 groups input into 3-byte chunks, each encoded as 4 characters. When input length is not divisible by 3, one or two
=padding characters align the output to a 4-character boundary. Standard Base64 requires padding; JWT omits it. - Is my data safe when using this tool?
- Yes. All encoding and decoding runs entirely in your browser. No data, text, or files are ever sent to any server.
Privacy & Security
All processing runs in your browser using standard JavaScript APIs. No data leaves your machine at any time.