Base64 Encode/Decode
Base64 Encode/Decode supports text and image workflows. Encode or decode text, convert images to Data URLs or raw Base64, or turn Data URLs / Base64 back into images for local preview and download.
Input Text
Character
0 / 500,000
Select or drop an image
Supports PNG, JPEG, WebP, GIF, SVG, BMP, AVIF, TIFF, ICO, HEIC and HEIF when the browser can read them.
Output Text
Output Text
Input Text
Character
0 / 500,000
MIME type for raw Base64
Raw Base64 does not include MIME information. Choose the original image type first so the preview can be generated automatically.
Paste an image Data URL, or paste raw Base64 and choose a MIME type to preview the image here.
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 detect the MIME type automatically and preview the image immediately.
Raw Base64 image data
provide the original image MIME type so the tool can preview it automatically and download it as an image.
Encoding Parameters & Variants
Usage Advice
Limitations & Compatibility
Privacy & Security
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 usually come from line wrapping, whether '=' padding is kept, URL-safe variants (-/_), or mismatched text encodings. When comparing results, make sure both sides use the same text encoding, disable automatic wrapping, and confirm whether URL-safe mode and padding are used.
Base64 represents 8 bits via 6; ~33% overhead is inherent
Yes. Emoji and multilingual text are handled as UTF-8 in Text mode. If the decoded result is actually non-text binary data, seeing garbled output is expected.