formaterTools Logo Formater Tools

Image to Base64 & Data URL Converter

Convert images to Base64 encoding or Data URLs instantly. Perfect for embedding images in HTML, CSS, or JavaScript. All processing happens in your browser - no file uploads to servers.

Supported formats: PNG, JPG, GIF, WebP, SVG, BMP, TIFF

Max size: 10MB

Both Outputs Are Always Generated โ€” Here's the Difference

This tool doesn't make you pick between "Base64" or "Data URL" output โ€” it reads your file with FileReader.readAsDataURL(), which produces a full data URL, then splits off everything after the first comma to get the raw Base64 payload too. So both boxes always populate from the same read: the Base64 box has just the encoded bytes, while the Data URL box has the complete data:image/png;base64,... string ready to drop straight into a src or background-image attribute. Use the Data URL when you're pasting directly into HTML/CSS; use the raw Base64 when an API or database field expects the encoded data without the MIME-type prefix.

The Tradeoff Nobody Mentions: Base64 Inflates Size by ~33%

Encoding to Base64 isn't free โ€” every 3 bytes of the original image become 4 characters of text, a fixed 4:3 expansion, so a 30KB PNG becomes roughly a 40KB Base64 string (the "Base64 Size" stat this tool shows you makes that concrete for your specific file). That overhead is why inlining images as data URIs is a genuinely good trade only in specific situations: small, frequently-reused assets like icons or UI sprites, where saving a separate HTTP request outweighs the extra bytes. For anything larger โ€” a hero photo, a full-size product image โ€” a normal image file reference with proper HTTP caching almost always beats embedding it as Base64, since the inflated inline version can't be cached independently or lazy-loaded the way a real <img src="photo.jpg"> can.

Format caveat: the file picker and this tool's underlying file.type.startsWith('image/') check will accept a TIFF file, but Chrome, Firefox, and Edge don't actually render TIFF images in an <img> tag โ€” only Safari does. If you upload a .tiff/.tif file in a Chromium or Firefox browser, the preview/dimension step (which loads the data URL into an Image() object to read width and height) can fail with "Error reading image" even though the Base64 encoding itself would have worked fine.

Where Inlining Actually Pays Off

  • โ€ข Small icon sprites in a CSS file: embedding a handful of small SVG or PNG icons as data URIs directly in your stylesheet's background-image rules avoids a separate round-trip per icon, which matters more on high-latency mobile connections than the extra bytes cost.
  • โ€ข Emailing HTML with an inline logo: many email clients strip or block linked external images by default, so a small logo embedded as a data URL in the HTML body can render even when remote images are disabled.
  • โ€ข Sending image data through a JSON API: if an API or webhook payload has to be pure JSON with no multipart file upload support, Base64-encoding a small thumbnail or avatar lets it travel as a normal string field.
  • โ€ข Quick prototypes and single-file demos: pasting a data URL into a CodePen-style single HTML file avoids needing to host a separate image asset just to get a mockup working.

Frequently Asked Questions

My image dimensions didn't show up โ€” why?

Dimensions are read by loading the converted data URL into an in-memory Image element and waiting for it to load. If your browser can't decode that image format at all (TIFF is the most common culprit outside Safari), that load step fails and you'll see an error rather than dimensions, even though the underlying Base64 encoding of the raw file bytes succeeded.

Should I use the Base64 string or the Data URL for my <img> tag?

Use the Data URL box โ€” it already has the data:image/...;base64, prefix your browser needs to know how to decode the string. The plain Base64 box is for contexts (APIs, database columns) that store just the encoded bytes and add their own metadata separately.

Is it ever a bad idea to inline an image as Base64?

Yes โ€” for anything beyond small, reused icons. A large inlined image bloats the HTML/CSS file it lives in, can't be cached separately by the browser the way a normal image file can, and adds roughly a third more bytes than the original file. For photos or large graphics, link to a normal image file instead.

Why is my Base64 string so much larger than my original file size?

That's expected: Base64 always expands binary data by about 33% because it re-encodes every 3 raw bytes as 4 text characters. Compare the "File Size" and "Base64 Size" stats this tool shows โ€” the ratio between them should be roughly 1.33.

Does this upload my image anywhere to generate the preview?

No โ€” the preview image, the Base64 string, and the Data URL are all produced by FileReader reading the file directly from your device's memory. The file itself is never sent over the network as part of this conversion.