Image to Base64 Converter

Select an image file and generate a Base64 data URL that can be copied into HTML, CSS, JSON, or test fixtures.

Runs in your browser No upload required Convert
Choose a local image. The file is read in your browser and converted into a data URL.

How to use Image to Base64

  1. Choose a local image file from your device.
  2. Review the file name, type, and size shown by the tool.
  3. Copy the generated data URL or raw Base64 payload.
  4. Use the output only where embedded assets are appropriate.

Why this tool exists

An image to Base64 converter turns a normal image file into text. That can be convenient for small icons, CSS demos, HTML prototypes, documentation snippets, email templates, and API examples where a separate asset file would make the example harder to share. CleanWebTools reads the selected file locally and outputs a data URL that includes the MIME type and encoded payload.

The main tradeoff is size. Base64 output is larger than the original binary file, and embedding large images directly in HTML or CSS can slow down pages and make source files hard to maintain. Use this tool for small assets, quick prototypes, self-contained examples, or debugging. For production websites, normal optimized image files are usually better.

Because the conversion runs in the browser, you can inspect private assets without sending them to a conversion service. The generated text can still contain sensitive visual content once decoded, so avoid pasting confidential output into logs, public tickets, or shared prompts unless the original image is safe to share.

This page focuses on the forward conversion from file to data URL. If you already have a Base64 image and need to preview it, use the Base64 to Image tool instead.

Common examples

  • Padding by leftover bytes: encoding the 3 bytes 'Man' (divisible by 3) yields 'TWFu' with zero '='; 'Ma' (2 bytes) yields 'TWE=' with one '='; 'M' (1 byte) yields 'TQ==' with two '='. The '=' count tells you how many real bytes the last 4-char group holds.
  • A 1x1 transparent PNG inlined as a data URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYPhfDwAChwGA60e6kgAAAABJRU5ErkJggg== — the fixed 'data:image/png;base64,' prefix is 22 characters before the payload, a legitimate inline replacement for a tracking-pixel request.
  • Inline-size decision: a 4 KB icon encodes to ~5.4 KB of Base64 and saving one HTTP round trip is worth it (webpack 5 asset modules inline below their 8 KB default and emit a file above it). A 100 KB hero photo balloons to ~136 KB of render-blocking, uncacheable text — leave that as a separate CDN-served file.

FAQ

Why does my data URI render in Chrome but show a broken image when I paste a base64url string from a JWT?

base64url (RFC 4648 section 5) swaps the standard '+' and '/' for '-' and '_' so the string survives in URLs and filenames, and it often drops the '=' padding. A data URI expects standard Base64 (section 4) with '+', '/' and proper '=' padding. Feeding a base64url payload into data:image/png;base64,... means the decoder hits '-' or '_' where it expects binary-meaningful symbols, so you get corrupt bytes and a non-rendering image. Convert '-'→'+', '_'→'/' and re-pad to a multiple of 4 first.

How much bigger will my image actually get, and can gzip on the page cancel it out?

Base64 inflates by a fixed 4/3 ratio, roughly 33.33%, because it spends 4 ASCII characters to carry every 3 bytes at 6 usable bits per character. A 102,400-byte image becomes 4 * ceil(102400/3) = 136,536 characters. Whether gzip or Brotli on the surrounding HTML claws that back depends entirely on the bytes: for already-compressed data like a PNG or JPEG the Base64 alphabet is near-incompressible, so compression recovers only about 10% of the added bytes. The compressed Base64 still ends up larger than the same binary served as its own file, which also keeps its own caching and Content-Encoding.

Should I Base64-encode an SVG, or is there a better encoding for it?

URL-encode it instead. SVG is plain text and most of its characters don't need escaping, so percent-encoding touches only a handful of symbols like '<', '>' and '#'. Base64 applies its flat ~33% inflation to every byte regardless. The URL-encoded data URI is almost always smaller, stays human-readable, and compresses better with gzip. The data:image/svg+xml,<...> URL-encoded form is recommended over base64 for exactly this reason.

By Alpha Loop · Last updated