Image to Base64 Converter

About this tool

This converter reads an image file from your device and turns it into a data URI: a single line of text that contains the whole image and can be pasted anywhere an image URL is expected. It uses the browser's FileReader API, so the file never leaves your computer. The preview shown above the output is drawn from the generated data URI itself, which is a quick check that the string is complete.

How to use the Image to Base64 Converter

1. Choose an image file from your device.
2. Preview the image and the generated data URI below it.
3. Copy the data URI and paste it directly into an src attribute or CSS background-image property.

What a data URI looks like

The output follows the data: URL format documented on MDN: data:[media type][;base64],[data]. For a PNG it begins data:image/png;base64, followed by the encoded bytes. The media type comes from the file type your browser reports, so a JPEG gives image/jpeg, a WebP image/webp and an SVG image/svg+xml. The first characters after the comma also give the format away, because every file of a given type starts with the same signature bytes: PNG data begins iVBORw0KGgo, JPEG begins /9j/ and GIF begins R0lGOD.

Why Base64 makes files about a third larger

Base64, defined in RFC 4648, reads a file three bytes (24 bits) at a time and writes each group as four characters, each carrying 6 bits using an alphabet of 64 letters, digits, + and /. Four characters for every three bytes is a 4 ÷ 3 ratio, so the encoded text is about 33% larger than the file. When the byte count isn't a multiple of three, the final group is padded with one or two = signs, which is why small files come out slightly more than a third bigger. The exact length of the Base64 part is 4 × ⌈bytes ÷ 3⌉ characters, and the data:image/png;base64, prefix adds another 22.

Worked example

A 24×24 PNG clock icon saved at 199 bytes encodes to 268 Base64 characters: 199 ÷ 3 rounds up to 67 groups, and 67 × 4 = 268. The last group holds a single byte, so the string ends in ==. With the prefix, the complete data URI is 290 characters. You can use it in HTML:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAY…" width="24" height="24" alt="Clock">

or in CSS:

.icon-clock {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAY…");
}

At the other end of the scale, a 200 KB (204,800-byte) photo becomes 273,068 characters — about 267 KB of text added straight into your HTML or CSS.

When inlining helps, and when it hurts

A data URI saves the browser a separate request for the image. That was a bigger win under HTTP/1.1, when browsers opened only a handful of connections per site; with HTTP/2 and HTTP/3, small requests are cheap, so today the benefit is often convenience — one self-contained file — as much as speed. The costs are worth weighing:

• No separate caching. The image is cached only as part of the file it's embedded in. Change one line of your CSS and visitors download the image again along with it, whereas a normal image file can stay cached across pages and deploys.
• Repeated bytes. Use the same data URI in three places and you ship it three times.
• Slower first render. Stylesheets block rendering until they have loaded, so large images inlined in CSS delay the whole page rather than loading alongside it.
• Compression only partly helps. gzip or Brotli win much of the overhead back in transfer. In our test, 200 KB of random, incompressible data (similar to a JPEG's contents) grew to 273 KB as Base64 and shrank to about 207 KB after gzip — but the browser still has to hold and decode the full string.

Common use cases

• Inlining a small icon or logo to avoid an extra network request
• Embedding an image directly into a CSS file or single-file HTML prototype
• Sending an image as text through a system that only accepts plain text fields
• Testing how a data URI image renders before committing it to production code

Tips and limits

• Shrink the image first. Every byte you save before encoding saves about 1.33 characters in the output, so run large files through the Image Compressor before converting.
• SVG doesn't strictly need Base64. SVG is already text, so it can also go in a data URI URL-encoded, which is often shorter. This tool always produces Base64, which works everywhere but isn't always the most compact option for SVG.
• Very large files. The tool doesn't cap file size, but a multi-megabyte image produces millions of characters, which can make the output slow to display and your code editor sluggish. Browsers accept very long data URLs — MDN lists 512 MB for Chromium and Firefox — so the practical limit is page weight, not the browser.
• Where it works. Data URIs work in src, CSS url() and similar places, but modern browsers block pages and links from navigating the whole tab to a data: URL, as an anti-phishing measure.

To encode or decode plain text rather than an image file — or to turn a Base64 string back into readable text — use the Base64 Encoder & Decoder.

Base64 image size chart

The length of the Base64 text is always 4 × ⌈bytes ÷ 3⌉ characters, so you can work out the size of a data URI before you convert anything. The chart below uses 1 KB = 1,024 bytes and adds the 22-character data:image/png;base64, prefix in the last column. For a JPEG the prefix is data:image/jpeg;base64,, one character longer.

Each character of the output is one byte of ASCII text, so the right-hand column is also roughly how many bytes the image adds to your HTML, CSS or JSON before compression.

Using the Base64 part without the prefix

Many APIs and JSON fields ask for "the Base64 of the image", meaning only the encoded data. That is everything after the first comma of the data URI. For example, a field might need "image": "iVBORw0KGgo…" rather than the full data:image/png;base64,iVBORw0KGgo… string. Going the other way, if a service hands you raw Base64 and you want to show it in a page, put the matching prefix in front of it. Check the API documentation, because sending the prefix to a field that expects raw data is a common cause of "invalid Base64" errors.

Standard Base64 vs Base64url

RFC 4648 defines two alphabets. Standard Base64, which this tool produces, uses + and / and pads with =. The "URL and filename safe" variant, Base64url, swaps those two characters for - and _ so the text can sit in a URL or file name. JSON Web Tokens use Base64url, which you can see in the JWT Decoder. If you have to pass a standard data URI inside a query string, percent-encode it first with the URL Encoder, because +, / and = have special meanings there.

If the image does not show up

• The string was cut off. Copy with the Copy data URI button rather than selecting text, and check that the pasted string ends the same way as the output.
• Line breaks were added. RFC 4648 says encoders must not insert line feeds unless another specification asks for them, but some editors and email tools wrap long lines. Remove any breaks inside the string.
• The browser cannot decode the format. A data URI only changes how the bytes are delivered. If a browser cannot display HEIC files, it cannot display them as Base64 either, so convert them first with HEIC to JPG.