Ttooleras
🔄

Base64 Encoder/Decoder

Encoders & Decoders

Encode and decode Base64 strings, files, and images instantly. Free, private — all processing in your browser.

Advertisement

The Base64 Encoder / Decoder is a free online tool that converts text, binary data, and files to and from Base64 — the universal binary-to-text encoding used across email (MIME), HTTP Basic Authentication, JSON Web Tokens (JWT), data URIs, and countless APIs. Whether you need to embed an image in CSS as a data URI, encode an API token, decode a JWT payload, or inspect a Base64-encoded webhook, this tool does it instantly in your browser — no uploads, no sign-up.

Base64 is not encryption. It is not a security mechanism. It is a deterministic, reversible encoding that represents arbitrary bytes using only 64 printable ASCII characters (A-Z, a-z, 0-9, +, /, with = as padding). That makes it safe to transmit binary data over text-only channels and to include binary content inside JSON, XML, HTML, or URL parameters. This encoder/decoder supports both the standard Base64 variant (RFC 4648 Section 4) and the URL-safe variant (RFC 4648 Section 5, used in JWT and OAuth), plus optional padding.

Base64 Encoder/Decoder — key features

Encode any text to Base64

Convert plain text, including Unicode (emoji, CJK, accents), to Base64. UTF-8 is used by default. Output appears instantly as you type.

Decode Base64 back to text

Paste a Base64 string and get the decoded UTF-8 text. Malformed input is detected and reported clearly.

Encode files to Base64

Drop any file (images, PDFs, fonts, binaries) into the tool and get a Base64 string ready to embed in a data URI, JSON payload, or SQL INSERT.

Standard and URL-safe variants

Toggle between standard Base64 (+, /, =) and URL-safe Base64 (-, _, optional padding) used by JWT, OAuth, and URL-embedded data.

Optional padding

Enable or disable the = padding characters. Required for strict RFC 4648 Section 4, optional for URL-safe Section 5 and JWT.

Copy, download, and share

Copy the output to clipboard or download as a .txt file. Perfect for pasting into email, APIs, or config files.

Live encoding and decoding

Results update as you type — no need to click a button. Speed is limited only by your browser.

100% private, client-side

All encoding and decoding happens in your browser using the native btoa() and atob() functions. Your data is never uploaded to any server.

How to use the Base64 Encoder/Decoder

  1. 1

    Choose encode or decode

    Select the Encode tab to convert text or files to Base64, or the Decode tab to convert Base64 back to text.

  2. 2

    Paste or type your input

    In the input field, paste the text you want to encode, the Base64 string you want to decode, or drop a file to encode.

  3. 3

    Select the variant

    Toggle between standard Base64 (for general use, email, databases) and URL-safe Base64 (for URLs, JWT tokens, OAuth).

  4. 4

    Choose padding option

    Enable padding for strict RFC 4648 compliance. Disable it for JWT and other contexts where padding is omitted.

  5. 5

    Copy the result

    The output updates instantly. Click Copy to put it on your clipboard, or Download to save it as a file.

Common use cases for the Base64 Encoder/Decoder

Web development

  • →Embed images as data URIs: Encode small images (icons, sprites, logos) as Base64 and embed them in CSS or HTML with `data:image/png;base64,...` to save HTTP requests.
  • →Embed fonts in CSS: Include custom web fonts directly in stylesheets as data URIs for simpler deployment and no CORS issues.
  • →Inline SVG and PDFs: Embed small SVGs or PDFs inline without separate file requests.

APIs and authentication

  • →HTTP Basic Authentication: Encode username:password as Base64 for the Authorization header: `Authorization: Basic dXNlcjpwYXNz`.
  • →JWT tokens: JSON Web Tokens consist of three Base64URL-encoded parts (header.payload.signature). Decode them to inspect claims and verify structure.
  • →OAuth client credentials: Encode client_id:client_secret as Base64 for OAuth 2.0 client credentials grant.
  • →API payloads with binary data: Send images, files, or binary blobs inside JSON or XML by encoding them as Base64 strings.

Email and messaging

  • →MIME email attachments: Email attachments are Base64-encoded in the MIME body. Decode them to inspect raw content.
  • →SMTP debugging: When debugging SMTP traffic, decode Base64-encoded SASL authentication and attachment bodies.

Storage and debugging

  • →Store binary in text databases: When a database column accepts only text, store binary data as Base64 strings (PostgreSQL, MySQL, SQLite).
  • →Inspect webhook payloads: Some webhooks send binary data as Base64 inside JSON. Decode to inspect the original content.
  • →Debug encoding issues: When data looks garbled, check whether it is Base64-encoded. Decoding it reveals the original bytes.

Base64 Encoder/Decoder — examples

Encode plain text

Standard Base64 encoding of a simple string.

Input
Hello, World!
Output
SGVsbG8sIFdvcmxkIQ==

Decode Base64 string

Reverse the encoding to get the original text back.

Input
VG9vbGVyYXMgaXMgZnJlZSE=
Output
Tooleras is free!

HTTP Basic Auth

Encode username:password pair for the HTTP Authorization header.

Input
admin:s3cr3t
Output
YWRtaW46czNjcjN0

URL-safe Base64 for JWT

URL-safe variant replaces + with - and / with _, and often omits padding.

Input
{"sub":"1234567890","name":"John Doe","admin":true}
Output
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

Data URI for small image

Base64-encoded image ready to use in HTML or CSS.

Input
<1x1 red pixel PNG file>
Output
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8/5+hHgAHggJ/PchI7wAAAABJRU5ErkJggg==

Unicode text with emoji

UTF-8 multi-byte characters work correctly.

Input
Hello 世界 🌍
Output
SGVsbG8g5LiW55WMIPCfjI0=

Technical details

Base64 encoding is defined in RFC 4648 (published October 2006, obsoleting RFC 3548). It is the canonical way to represent binary data as text for transmission or storage in text-only contexts. The encoding takes 3 bytes (24 bits) of input and produces 4 characters of output (6 bits per character, since 2^6 = 64). If the input length is not a multiple of 3, the output is padded with = signs to maintain alignment.

The Base64 alphabet (standard):

``
Index 0-25: A-Z
Index 26-51: a-z
Index 52-61: 0-9
Index 62: +
Index 63: /
Padding: =
``

The Base64 alphabet (URL-safe):

``
Index 62: - (replaces +)
Index 63: _ (replaces /)
Padding : optional (often omitted)
``

Encoding algorithm:

1. Take 3 input bytes (24 bits).
2. Split the 24 bits into 4 groups of 6 bits.
3. Map each 6-bit group to the corresponding character in the Base64 alphabet.
4. If the input length is not divisible by 3, pad the input with zero bits and add = characters to indicate padding (one = if 2 input bytes remain, two == if 1 input byte remains).

Size overhead: Base64 encoding increases data size by approximately 33% (from 3 bytes to 4 characters plus potential padding). The formula is ceil(n / 3) * 4 characters for n input bytes. A 100 KB file becomes ~134 KB when Base64-encoded.

Common variants:

- RFC 4648 Section 4 — standard Base64 with +, /, and = padding. Used by most systems (MIME, OpenSSL, base64 CLI).
- RFC 4648 Section 5 — URL-safe Base64 with -, _, and optional padding. Used by JWT (RFC 7519), OAuth tokens, URL-embedded data.
- RFC 2045 (MIME) — Base64 with line breaks every 76 characters. Used in email attachments.
- RFC 3501 (IMAP) — modified Base64 using , instead of /. Used only in IMAP mailbox names.

Common problems and solutions

⚠Base64 is not encryption

Anyone can decode Base64 instantly — it provides zero security. Never use Base64 to protect passwords, API keys, or sensitive data. Use proper encryption (AES-GCM, age, libsodium) for secrets.

⚠Mixing standard and URL-safe variants

If you encode with standard Base64 but decode with URL-safe decoder (or vice versa), you get garbled output. Always match the variant. JWT and OAuth use URL-safe; email and most APIs use standard.

⚠Missing or incorrect padding

Standard Base64 requires = padding to align the output to multiples of 4 characters. JWT omits padding. If you see `Invalid Base64` errors, check whether padding is required by the consumer and add or remove = as needed.

⚠Line breaks in Base64 output

MIME (email) Base64 wraps at 76 characters per line. Many APIs reject line breaks. Strip `\n` and `\r` from Base64 strings before decoding, or enable single-line output in your encoder.

⚠Character encoding mismatch

Base64 encodes bytes, not characters. If you encode a string as Base64 in one character encoding (UTF-8) and decode in another (Latin-1), you get mojibake. Always use UTF-8 for text.

⚠Encoding large files in the browser

Encoding a 100+ MB file as Base64 can crash a browser tab due to memory limits. For very large files, use streaming APIs or do the encoding server-side or in a Web Worker.

⚠Base64 inflates payload size

Base64 adds ~33% overhead. If you are sending many large images through APIs, consider binary-compatible formats (multipart/form-data, protobuf, or direct file uploads to object storage) instead of JSON with Base64 strings.

⚠Misidentifying other encodings as Base64

Strings that look like Base64 may actually be Base32, Hex, URL-encoded, or JWT segments. Verify the character set (Base64 uses A-Z, a-z, 0-9, +, /, =) before decoding. Base32 uses a different 32-character alphabet.

Base64 Encoder/Decoder — comparisons and alternatives

Base64 vs Base32: Base32 uses 32 characters (A-Z and 2-7), producing longer output (~60% overhead vs Base64 ~33%) but avoiding case sensitivity issues. Used in TOTP/HOTP tokens and some DNS systems.

Base64 vs Hexadecimal: Hex uses 16 characters (0-9, A-F) with exactly 2 characters per byte — 100% overhead (double the size). Hex is simpler to read digit-by-digit, but Base64 is more compact. Hex is preferred for small fixed-size values (hashes, UUIDs); Base64 is preferred for arbitrary binary data.

Base64 vs URL encoding: URL encoding (percent-encoding, RFC 3986) encodes only unsafe characters (%20 for space, %2F for /). It is not suitable for binary data because it may produce much longer output. Use Base64 for binary data, URL encoding for query-string text.

Base64 vs Base85 / Ascii85: Base85 uses 85 characters and is ~25% overhead — more efficient than Base64. Used in PostScript, PDF, and Git binary patches. Less common outside those niches due to use of characters that need escaping in JSON/XML.

Base64 vs binary (raw): Raw binary has zero overhead and is the most efficient. But it cannot be embedded in text formats (JSON, XML, HTML, URLs, email bodies). Use Base64 when you need text-compatible encoding; use raw binary when the channel supports it (HTTP body with proper Content-Type, multipart uploads).

Base64 vs Base64URL (URL-safe): Same algorithm, different alphabet for positions 62 and 63 (+ becomes -, / becomes _). Plus padding is often omitted in URL-safe contexts. Mandated by JWT (RFC 7515) and used in OAuth, OpenID Connect, and other URL-embedded tokens.

Frequently asked questions about the Base64 Encoder/Decoder

▶What is Base64 encoding?

Base64 is a binary-to-text encoding scheme that represents any binary data (images, files, bytes) using 64 printable ASCII characters: A-Z, a-z, 0-9, +, /, and = for padding. It is defined in RFC 4648 and is the standard way to include binary data in text-only formats like JSON, XML, HTML, email, and URLs.

▶Is Base64 encryption or encoding?

Base64 is encoding, not encryption. Anyone can decode Base64 instantly without a key. Never use Base64 to hide passwords, secrets, or sensitive data. Base64 is just a way to represent bytes as text so they can pass through text-only channels safely. For security, use proper encryption (AES-GCM, RSA, libsodium, age).

▶What is the difference between standard and URL-safe Base64?

Standard Base64 (RFC 4648 Section 4) uses +, /, and =. It is used by email (MIME), most APIs, and the command-line base64 tool. URL-safe Base64 (RFC 4648 Section 5) replaces + with - and / with _, and often omits padding. It is used by JWT (RFC 7515), OAuth tokens, OpenID Connect, and anywhere the encoded string appears in a URL or filename.

▶Why does Base64 end with = signs?

The = padding ensures the output length is a multiple of 4 characters. Since Base64 encodes 3 input bytes into 4 output characters, padding is needed when the input is not divisible by 3. One = means the last group had 2 input bytes; two == means it had 1 input byte; no = means the input length was a multiple of 3. Some variants (JWT) omit padding entirely.

▶How much larger is Base64-encoded data?

Base64 increases data size by approximately 33%. Every 3 bytes of input produce 4 bytes of output (plus 1-2 padding bytes if needed). The exact formula is ceil(n / 3) * 4 characters for n input bytes. A 100 KB file becomes ~134 KB. If line wrapping is added (MIME format, 76 chars per line), add another ~1.5% for newlines.

▶Can I encode an image with this tool?

Yes. Drop any image file (PNG, JPG, GIF, WebP, SVG) into the encoder. You get a Base64 string you can paste into a data URI: data:image/png;base64,.... This is useful for embedding small images in CSS, HTML emails, or JSON responses. For large images, prefer serving the image directly — Base64 inflates size and blocks caching.

▶How do I decode a JWT token?

A JWT has three parts separated by dots: header.payload.signature. Split on the dots and decode each part as URL-safe Base64 without padding. The header and payload decode to JSON; the signature is raw bytes used to verify the token. Tooleras also has a dedicated JWT Decoder that handles this automatically.

▶Is this Base64 encoder safe for secrets?

Yes — all encoding and decoding happens entirely in your browser. The tool uses JavaScript's built-in btoa() and atob() functions (with Unicode handling via TextEncoder/TextDecoder). Nothing is sent to any server. You can safely encode/decode API tokens, auth headers, and credentials. Check the Network tab in DevTools to verify no outbound requests are made.

▶What encoding (UTF-8, UTF-16, Latin-1) does this tool use?

For text input, UTF-8 is used by default — this is the universal standard for web content and the only correct choice for any modern system. Legacy systems may use Latin-1 (ISO-8859-1) or UTF-16; if you are decoding legacy data, look for a character encoding option. Encoding ASCII text (a-z, 0-9) produces identical Base64 output in any encoding.

▶Why does my Base64 string fail to decode?

Common reasons: (1) Wrong variant — standard vs URL-safe mismatch, (2) Incorrect padding — missing or extra = signs, (3) Whitespace or line breaks — strip \n, \r, spaces before decoding, (4) Invalid characters — characters outside A-Z, a-z, 0-9, +, /, =, (5) Truncated input — the string was cut off in transit. Check each of these and re-decode.

Additional resources

Advertisement

Related tools

All Encoders & Decoders
0️⃣

Binary to Text Converter

Convert binary code (0s and 1s) to readable text in ASCII or Unicode, with configurable grouping and separator options.

🔐

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-512 hashes for text and files

🔢

Hex to Text Converter

Convert hexadecimal byte sequences to readable ASCII or UTF-8 text with flexible input formatting.

🔏

HMAC Generator

Generate HMAC signatures (SHA-256, SHA-512) for API auth and webhook verification

🖼️

Image to Base64

Convert any image to Base64-encoded data URI for embedding directly in HTML src, CSS background, or JSON data fields.

🎫

JWT Decoder

Decode and inspect JSON Web Token (JWT) headers, payloads, and signatures

Learn more

How to Decode a JWT: A Practical Debugging Guide (with the Base64URL Gotcha Nobody Warns You About)

17 min read

UUID v4 vs v7: The Default Has Quietly Changed

22 min read

MD5, SHA-1, SHA-256: Three Kinds of Hashing Everyone Confuses

24 min read

Explore more tools

200+ free tools that run in your browser.

Browse all tools →