Base64 Encoder & Decoder

Encode text or files to Base64 and decode Base64 back to text. Supports Base64URL for JWTs and URLs, no-padding output, 76-character MIME chunk splitting, per-line encoding, and image-to-data-URI conversion. Nothing leaves your browser.

base64.tool
Output

When You Actually Need Base64

You need Base64 when binary or special-character data must travel through a system built for plain text. Three common situations: embedding images directly in HTML or CSS without a separate file request, HTTP Basic Auth headers (Authorization: Basic dXNlcjpwYXNz where the value is Base64 of user:pass), and passing binary data through JSON APIs that only accept strings.

Encoding Options Explained

  • Base64URL — replaces + with - and / with _, making the output safe in URLs and filenames. Required for JWT tokens. Ticking this automatically handles the substitution.
  • No padding — removes the trailing = signs. The receiver can infer the correct length without them. Used in JWT (which always drops padding) and some URL contexts where = needs escaping.
  • Split into 76-char MIME chunks — inserts a line break every 76 characters. This is the MIME (RFC 2045) standard for email attachments and some XML/HTML embedding contexts where very long lines cause problems.
  • Encode each line separately — encodes each line of input as an independent Base64 string. Useful for batch-encoding a list of values in one pass.

Base64URL vs No Padding — What is the Difference?

These are separate options that can be combined. Base64URL changes which characters are used (-_ instead of +/). No padding removes the = signs at the end. JWT uses both together — Base64URL encoding without padding. You can tick both checkboxes to match exactly what JWTs expect.

Image to Data URI

The Image tab converts any PNG, JPG, GIF, SVG or WebP image into a Base64 data URI ready to paste directly into HTML or CSS. The format is data:image/png;base64,... which browsers load inline without a separate HTTP request — useful for small icons and logos.

Frequently Asked Questions

No. Base64 is encoding, not encryption. Anyone who sees a Base64 string can decode it instantly without any key or password. The string dXNlcjpwYXNz decodes to user:pass — no secret needed. Do not use Base64 to hide sensitive data. Use it only for safe transport of binary data through text-only channels.
Standard Base64 uses + and / which are special characters in URLs and need percent-encoding as %2B and %2F. Base64URL replaces + with - and / with _ so the output is safe in URLs, filenames, and tokens without any percent-encoding. JWT tokens always use Base64URL. When decoding, this tool automatically detects and handles both formats.
Base64 encodes 3 bytes into 4 characters. If the input length is not a multiple of 3, padding characters (=) fill the remainder — one = means one spare byte, two == means two spare bytes. This is normal and required by the standard. Enable "No padding" to remove them if your receiver supports unpadded Base64 (JWT always drops padding).
MIME (RFC 2045) — the standard for email attachments — requires Base64-encoded data to be split into lines of no more than 76 characters each. Without this, some email clients and SMTP servers may reject or corrupt long Base64 lines. Enable "Split into 76-char MIME chunks" when your Base64 output will be used in email headers, MIME multipart messages, or any system that enforces line length limits.
A JWT has three Base64URL-encoded parts separated by dots. The payload is the middle part. Paste just that middle section into the Decode input and click Decode. The tool automatically handles Base64URL format. You can also use the JWT Decoder tool on WTEC which decodes all three parts at once and shows every claim in a readable format.
The Upload File button handles text files up to 5MB. For binary files like images, use the Image tab — drag and drop any image to get a Base64 data URI. For other binary formats like PDFs or ZIP files, browser JavaScript handles text encoding differently from raw binary, so a desktop tool will give more reliable results for those file types.
Almost always a character encoding mismatch. Base64 does not store information about the original text encoding. If the text was encoded as ISO-8859-1 or Windows-1252 but you are decoding expecting UTF-8, characters outside ASCII will appear wrong. Try re-encoding the original text from its source application rather than copying an already-encoded string.