Base64 Encode/Decode
Base64 Encode/Decode
Base64 Encode/Decode: Encode and decode Base64 for text and images with UTF-8, URL-safe, MIME, Data URL, and raw Base64 workflows.
Quick Start
Common Scenarios
URL/JWT
Prefer the URL‑safe variant (−/_); the trailing '=' may be omitted to avoid escaping issues
Email/MIME
When wrapping is required, use MIME 76 columns (CRLF); for the web, don't wrap. This tool provides 76‑column wrapping and an LF/CRLF toggle
Multiline text
enable Per‑line encode to encode each line independently
MIME/PEM
enable 76‑column wrapping; enable LF line breaks when needed
Data URL
When embedding, generate data:[mime];base64,…; the decoder auto‑extracts the part after the comma
Round‑trip verify
encode then immediately decode to ensure fidelity
Image upload
Keep the original bytes and switch between Data URL and raw Base64 output without re-uploading
Image Data URL
Paste data:image/...;base64,... to auto-detect MIME and rebuild a previewable image
Raw Base64 image data
Supply the original image MIME explicitly before reconstructing or downloading
Extended workflow
encode base64, decode base64, and base64 converter can be handled in the same review flow, so you can verify results before copying or exporting.
Encoding Parameters & Variants
Usage Advice
Limitations & Compatibility
Session Controls
FAQ
Base64 is a scheme to safely represent arbitrary binary data as printable text characters. It first appeared in email's MIME standard (1990s, RFC 1521/2045) and was later unified by RFC 4648. The goal is not “encryption” but reliable carriage of bytes over text‑oriented channels. How it works: every 3 bytes (24 bits) are split into four 6‑bit blocks and mapped to 64 characters A–Z, a–z, 0–9, +, /. If the source length is not a multiple of 3, “=” padding aligns the length. Size typically grows by ~33%. Variants & choices: RFC 4648 defines the URL‑safe variant, using “-” and “_” instead of “+” and “/”, and the trailing “=” may be omitted. Prefer URL‑safe for URLs, Cookies and JWT; use standard Base64 (keep +/ and =) for legacy/MIME toolchains. This tool defaults to URL‑safe; the decoder accepts both variants. Examples: ??? → standard Pz8/, URL‑safe Pz8_; ~~~ → standard fn5+, URL‑safe fn5-. Data URL: when embedding, use data:[mime];base64,… and decode the part after the comma (this tool extracts it automatically). Milestones (short): 1993 RFC 1521 (MIME v1, Ned Freed & Nathaniel Borenstein) → 1996 RFC 2045 (MIME update, replaces 1521) → 2003 RFC 3548 (Simon Josefsson, abstracts Base16/32/64) → 2006 RFC 4648 (Simon Josefsson, unifies and defines Base64URL, obsoletes 3548). Also: 1993 RFC 1421 (PEM, J. Linn) used Radix‑64 (akin to Base64) to carry binaries in mail. Security note: Base64 is reversible formatting, not confidentiality or integrity. Encrypt first, then encode.
No. Anyone can decode it. Encrypt first if you need confidentiality
Only A–Z, a–z, 0–9, +, / and = are allowed, and length must be valid
Differences often come from line wrapping, whether '=' padding is kept, URL‑safe variant (−/_), and implementation details. Use UTF‑8, disable wrapping, and decide whether to use URL‑safe and keep padding
Base64 represents 8 bits via 6; ~33% overhead is inherent
Yes with UTF‑8. Non‑text binaries may look like gibberish after decode