Image to Base64

About Image to Base64

How Base64 Image Encoding Works

Binary files (like images) contain bytes with values from 0 to 255. Base64 maps every three bytes to four ASCII characters from a set of 64 safe characters (A-Z, a-z, 0-9, +, /). The result is a text string that can be safely embedded anywhere that accepts text.

Concept	Explanation
Input	Binary image file (JPEG, PNG, WebP, GIF, SVG)
Output	ASCII text string starting with data:image/[type];base64,
Size increase	~33% larger than the original binary (3 bytes become 4 characters)
Encoding method	FileReader.readAsDataURL() in the browser

Data URL Format

A complete data URL includes a prefix that tells the browser what type of content follows:

Image Type	Data URL Prefix
PNG	data:image/png;base64,
JPEG	data:image/jpeg;base64,
WebP	data:image/webp;base64,
GIF	data:image/gif;base64,
SVG	data:image/svg+xml;base64,

The toggle in this tool lets you include or exclude the prefix. Include it when pasting directly into an img src or CSS url(). Exclude it when your code adds the prefix separately or when you need the raw encoded string.

When to Use Base64 Images

Use Case	Why Base64 Helps	Size Recommendation
Small icons and UI sprites	Eliminates an HTTP request per image - faster page load	Under 2 KB original (~2.7 KB encoded)
Email templates	Many email clients block external images by default - inline images display immediately	Under 50 KB to keep email size reasonable
Single-file HTML documents	Everything in one file - no external dependencies	Under 100 KB for practical use
CSS backgrounds	Eliminates a render-blocking request for small backgrounds	Under 5 KB original
JSON payloads / API responses	Send image data as text in a JSON field	Depends on API limits
Offline web applications	Images bundled in code, no network needed	Under 50 KB per image
Configuration files	Embed logos or icons in YAML, TOML, or JSON config	Under 10 KB

When NOT to Use Base64 Images

Scenario	Why Not	Better Alternative
Large photographs (100 KB+)	33% size increase makes page much heavier, not cacheable separately	Serve as a regular file with proper caching headers
Images used on multiple pages	Base64 is re-downloaded with every page load - no browser caching	External file gets cached and reused across pages
Many images on one page	Each inline image bloats the HTML/CSS, slowing initial parse	Lazy-load external images as the user scrolls
Dynamic/frequently updated images	Changing the image means regenerating the Base64 string	URL reference that points to the latest version

Size Comparison Reference

Original File Size	Base64 String Size	Base64 String Length (chars)	Practical?
500 bytes	~667 bytes	~670 characters	Yes - perfect for tiny icons
2 KB	~2.7 KB	~2,700 characters	Yes - good for small UI elements
10 KB	~13.3 KB	~13,600 characters	Yes - acceptable for inline use
50 KB	~66.7 KB	~68,000 characters	Borderline - consider external file
200 KB	~266.7 KB	~273,000 characters	No - serve as external file
1 MB	~1.33 MB	~1,365,000 characters	No - will slow down your editor and page

If you need to encode or decode other types of data (not just images), try the Base64 encoder and decoder. For reducing image file size before encoding, the image compressor can help. All conversion happens locally in your browser using the FileReader API - no image data is transmitted to any server.

The Base64 Alphabet and Padding

Base64 uses exactly 64 printable ASCII characters: A-Z (0-25), a-z (26-51), 0-9 (52-61), plus the symbols + (62) and / (63). The = sign is reserved for padding. This alphabet is defined in RFC 4648, the IETF standard that governs Base64 across browsers, servers, and programming languages.

Worked example: encode the three bytes for the ASCII text "Cat" (bytes 67, 97, 116 or binary 01000011 01100001 01110100). Concatenate to a single 24-bit block: 010000110110000101110100. Split into four 6-bit groups: 010000 (16), 110110 (54), 000101 (5), 110100 (52). Index into the alphabet: Q, 2, F, 0. Result: "Q2F0". That is the same four characters you would get from btoa("Cat") in any browser console. Every three bytes of input always produce exactly four characters of output - that is where the 4/3 (33.3%) size overhead comes from.

When the input is not a multiple of three bytes, Base64 pads the output with = so the final string length is always divisible by four. One leftover byte gives two = signs, two leftover bytes give one = sign. This is why most encoded strings end with =, == or have a length that is a clean multiple of four.

How Big Will the Encoded String Actually Be?

The exact encoded length in characters is 4 × ceil(n / 3), where n is the original byte count. For a 10,000-byte PNG: 4 × ceil(10000 / 3) = 4 × 3334 = 13,336 characters. Add the data URL prefix (around 22 characters for PNG) and you reach 13,358 characters on the wire. Gzip or Brotli compression on the response recovers some of the overhead because Base64 text compresses better than raw binary image data does on its own, but realistic gzip savings on Base64-encoded images are in the 2-5% range - not enough to offset the initial 33% penalty.

Google's web.dev guide on inline images suggests inlining only assets small enough that the saved HTTP request wins against the added HTML parse cost. As a rough rule, inline anything under 1-2 KB, keep anything above 10 KB external, and benchmark the grey zone.

Browser Support and the FileReader API

This tool relies on the FileReader API, which has been supported in every major browser since 2012 (Chrome 13, Firefox 7, Safari 6, Edge all versions). The MDN readAsDataURL documentation confirms that the output is a base64-encoded data URL with the MIME type taken from the file's type property. Files without a recognised MIME type default to application/octet-stream, which is why this tool falls back to image/png when the browser cannot determine the type from the file extension.

Modern browsers also expose btoa() and atob() for Base64 on strings, but these only work on ASCII. For binary data (including images), FileReader or the newer TextEncoder + manual byte conversion are required. Node.js uses Buffer.from(data).toString('base64'), Python uses base64.b64encode(), and they all produce the same RFC 4648 output.

Security, Privacy, and CSP Considerations

Data URLs are treated as a distinct origin by the browser, which means a Base64-encoded SVG image cannot access cookies or call APIs on the parent page. That said, SVG is itself an XML format that can contain <script> tags - an untrusted SVG embedded in an <img> tag is safe (images never execute scripts), but the same SVG embedded via <object>, <iframe>, or CSS background on some older configurations can execute code. OWASP's File Upload Cheat Sheet recommends sanitising SVG uploads before converting or serving them.

Content Security Policy (CSP) treats data: URLs as a separate source. If a site sets img-src 'self', Base64-encoded images embedded inline will be blocked. The fix is to add data: to the img-src list: img-src 'self' data:. Be aware that permitting data: on script-src or object-src is risky and should normally be avoided.

Because this converter runs entirely in the browser, no image data leaves your device. The encoded string is produced in local memory by the FileReader API and stays there until you close the tab.

Common Mistakes and Gotchas

Mistake	Why It Fails	Fix
Pasting raw Base64 into an img src without the prefix	Browser treats the string as a relative URL, returns 404	Include the full data:image/png;base64, prefix
Wrapping the Base64 string in quotes inside a CSS url() and breaking the line	Line breaks inside the URL invalidate the data URL	Keep the entire Base64 string on a single line, use double quotes around it
Using the wrong MIME type (e.g. image/jpg instead of image/jpeg)	Some browsers fail to render the image	Use the canonical IANA MIME type - image/jpeg, image/png, image/webp
Inlining the same logo on every page of a multi-page site	Forces re-download on every navigation, no caching benefit	Serve the logo as a cached external file referenced by a clean URL
Putting a 500 KB hero image as a data URL in HTML	Slows initial HTML parse, blocks first paint	Lazy-load the hero as an external image with loading="lazy"
Storing Base64 images in a database instead of on disk	Bloats row sizes, slows queries, no CDN caching	Store the binary on object storage (S3, R2) and keep only the URL in the database

Practical Workflow Tips

If your goal is a fast page, always compress first, then encode. Running a PNG through a lossless optimiser like OxiPNG or Squoosh before Base64-encoding it can cut 30-60% off the source bytes, and that reduction carries through to the encoded output. For a favicon you are about to inline in HTML, generate it with the favicon generator, optimise it, then Base64-encode the optimised version - the final inline string will be markedly smaller than encoding the raw output from a design tool.

SVGs are a special case. Because SVG is already text, many developers prefer URL-encoding rather than Base64-encoding for CSS backgrounds. URL-encoded SVG is typically 20-30% smaller than the Base64 equivalent because Base64's 4/3 overhead is wasted on content that was already ASCII. The URL-encoder tool by Yoksel is a well-known reference. Base64 still has its place for SVGs - it is safer across older CSS parsers and keeps quoting consistent - but know that URL-encoding is often the leaner choice.

For email templates, Gmail, Outlook.com, and Yahoo Mail all render inline data URLs, but desktop Outlook (Word rendering engine) has historically dropped them. The 2024 "Can I Email" data at caniemail.com shows Base64 images are supported in around 75% of email clients by market share. For broad compatibility, pair inline images with a normal src fallback or accept that desktop Outlook users will see alt text.

Sources

• RFC 4648 - The Base16, Base32, and Base64 Data Encodings (IETF)
• MDN - The data: URL scheme
• MDN - FileReader.readAsDataURL()
• web.dev - When to embed images with Base64
• OWASP - File Upload Cheat Sheet
• Can I Email - Base64 image support across email clients