All encoding and decoding happens entirely in your browser. No data is sent to any server.

About This Tool

Base64 is an encoding scheme that converts binary data into a string of 64 printable ASCII characters. It is widely used to embed binary data (images, files) in text-based formats like JSON, HTML, CSS, and email (MIME). This tool encodes plain text or file contents to Base64 and decodes Base64 strings back to readable text, all in your browser using the native btoa() and atob() functions. It also supports the URL-safe Base64 variant (using - and _ instead of + and /).

How to Use

  1. Select Encode or Decode mode using the toggle.
  2. Type or paste your text into the input field.
  3. The result updates instantly. Click Copy to copy to clipboard.
  4. To encode a file, use the file upload option, the file content is converted to a Base64 data URI.

Common Use Cases

  • Embedding a small image as a data URI in CSS or HTML. Drop an icon or small PNG/SVG into the File to Base64 tab, then click Download as Data URL. Paste the result into a background-image: url(...) rule or an <img src="data:image/png;base64,..."> tag to save an extra HTTP request for tiny assets.
  • Decoding a JWT payload segment. A JSON Web Token has three dot-separated parts. Copy the middle segment (the payload) into the input, switch to the URL-safe tab since JWTs use URL-safe Base64 without padding, and click Decode to read the claims as plain JSON.
  • Encoding binary attachment data for an email or webhook API. Many REST APIs (email providers, chat webhooks, file upload endpoints) require attachment bytes as a Base64 string inside a JSON body. Drop the file in the file tab, copy the Base64 output, and paste it directly into the API's attachment field.
  • Reading a Basic Auth header value. HTTP Basic Authentication sends credentials as Basic base64(username:password). Paste the portion after "Basic " into the decoder to see the raw username and password pair during debugging.
  • Sharing a short binary token in a text-only field. Configuration files, environment variables, and some databases only accept plain text. Encoding a small binary key or secret to Base64 lets it travel safely through text-only channels and be decoded back exactly on the other end.

Base64 vs Base32 vs Hex

All three are encoding schemes for representing binary data as text, they differ in density and character set. Base64 uses 64 characters (A-Z, a-z, 0-9, plus two symbols) and packs 3 bytes into 4 characters, making it the most compact of the three, roughly 33 percent larger than the original binary. Base32 uses only 32 characters (typically A-Z and 2-7), which makes it case-insensitive and safe to read aloud or type by hand, at the cost of being about 60 percent larger than the original data, this is why TOTP secret keys use Base32 rather than Base64. Hex (base-16) uses only 0-9 and A-F, doubling the size of the original data, but every byte maps to exactly two readable characters which makes it the easiest format to eyeball and debug. None of the three provide confidentiality, they are encodings, not encryption, and any of them can be reversed instantly without a key.

Troubleshooting

  • Decoded output looks like garbage or mojibake. This usually means the original text was encoded with a different character set than UTF-8, such as Latin-1 or Windows-1252, before it was Base64 encoded. This tool assumes UTF-8 on decode, if the source system used a different encoding the bytes will map to the wrong characters.
  • Decode fails with an "Invalid Base64 string" error. Standard Base64 only contains letters, digits, plus, slash, and padding equals signs. Stray line breaks, quotation marks copied along with the string, or URL-safe characters (dash and underscore) pasted into the standard Text tab will all cause this. Try the URL-safe tab if the string came from a JWT or URL.
  • The output is missing or has extra equals sign padding. Some systems (JWTs, many URL-safe implementations) omit the trailing padding entirely. This tool's URL-safe mode strips padding automatically on encode and re-adds it internally on decode, so mismatched padding from another source rarely matters, if it does, add or remove equals signs until the length is a multiple of 4.
  • File encoding produces an extremely long string that fails to paste somewhere. Base64 inflates size by about 33 percent, a 3 MB file becomes a 4 MB string. Some form fields or API request size limits will reject that. Compress or resize the source file before encoding if this happens.

Frequently Asked Questions

Is Base64 the same as encryption?

No. Base64 is an encoding scheme, not encryption. It converts data to a different format but provides no confidentiality, anyone can decode a Base64 string without a key. Do not use Base64 to "hide" sensitive data.

What is URL-safe Base64?

Standard Base64 uses + and / which have special meanings in URLs. URL-safe Base64 replaces them with - and _. It's used in JWTs, OAuth tokens, and anywhere Base64 appears in a URL or filename.

Why does Base64 output end in = signs?

Base64 encodes every 3 bytes of input into 4 characters. If the input length isn't a multiple of 3, padding characters (= or ==) are added to make it so. Some implementations omit padding, both forms decode identically.

Why is my Base64 string bigger than the original file?

Base64 represents every 3 raw bytes using 4 text characters, so the encoded size is always about 133 percent of the original. This overhead is the tradeoff for making binary data safe to store or transmit as plain text.

Can I Base64 encode an entire file, not just text?

Yes. Use the File to Base64 tab, drop or choose any file (image, PDF, zip, anything), and the tool reads its raw bytes and encodes them, exactly the same way btoa() handles a data URL in the browser. The result can be pasted into HTML, CSS, JSON payloads, or config files.