Image to Base64 Converter

How to use the image to Base64 converter

1. Drop your images. Drag in one or more PNG, JPG, WebP, GIF, SVG, HEIC, AVIF, BMP, ICO, or PDF files, or click to browse. iPhone HEIC photos are decoded to JPEG right in your browser before encoding, so they work everywhere. Nothing leaves your device.
2. Optionally prepare the image first. The Processing menu defaults to encoding the file exactly as uploaded, but you can also compress it (a quality slider from 20 to 100 plus a max-edge cap of 1920, 1280, 800, or 480 px), resize to an exact width or height with aspect ratio locked, convert to JPEG, PNG, or WebP, or rotate and flip in 90° steps. SVG and PDF files pass through untouched so their vector data stays intact.
3. Pick an output format. Choose a full data URI (data:image/png;base64,…), the raw Base64 string only, a CSS background-image rule, or a complete HTML <img> tag with alt, width, and height attributes filled in. A checkbox wraps long strings at 80 characters if your editor or config format prefers short lines. Switching formats updates every snippet instantly; after changing processing options, click Re-encode all.
4. Copy or download. Each file gets its own card with a preview thumbnail, dimensions, file size, MIME type, and a Copy button. Use Copy all to grab every snippet at once (each labelled with its filename), or Download .txt to save them as a single text file. Add images appends more files to the batch; Clear all starts over.

What Base64 encoding and data URIs actually are

Base64 is a binary-to-text encoding scheme, standardised in RFC 4648, that represents arbitrary bytes using 64 safe ASCII characters: A–Z, a–z, 0–9, +, and /, with = as padding. Every 3 bytes of binary data become 4 encoded characters, which is why a Base64 string is always about a third larger than the original file. The point of the exchange is portability: an image encoded this way is plain text, so it can travel through any channel built for text — an HTML document, a stylesheet, a JSON payload, an email body — without corruption.

A data URI (RFC 2397) wraps that Base64 string in a small addressing scheme the browser understands: data:[mediatype][;base64],<data>. For a PNG, that looks like data:image/png;base64,iVBORw0KGgo…. The prefix tells the browser what kind of resource follows and how it is encoded, so the string can be used anywhere a URL is expected — an <img src>, a CSS url(), a favicon <link> — and the browser decodes and renders it directly from the document, with no network request at all. Data URIs are supported by every modern browser; the old 32 KB cap that Internet Explorer 8 imposed is long gone, and current engines handle multi-megabyte strings, though very large ones bloat the document and slow parsing.

Where inlined Base64 images are used

Once an image is a text string, it can live inside other files instead of alongside them. The common homes:

• CSS. background-image: url("data:image/svg+xml;base64,…") is the classic use — small icons, textures, chevrons, and loading spinners embedded straight into the stylesheet, so they arrive with the CSS and never trigger a separate request.
• HTML. An inline <img src="data:…"> renders with zero additional fetches. This is how single-file HTML documents, exported reports, offline pages, and email templates carry their images.
• SVG. An <image href="data:…"> element lets you embed a raster photo or logo inside a vector file, producing one self-contained .svg asset.
• Favicons. A <link rel="icon" href="data:image/png;base64,…"> ships the site icon without a favicon.ico file — handy for prototypes and single-page demos.
• JSON and APIs. Binary can’t ride inside JSON, so APIs that accept image uploads in a JSON body — including many AI and OCR endpoints — expect the image as a Base64 field.
• Email. Data-URI images in HTML email are a mixed bag: Apple Mail renders them, but Gmail and most Outlook versions block or strip them, which is why production email still relies on hosted images or CID attachments. Test before you commit.

The raw Base64 string (without the data: prefix) is what you want for JSON payloads, config files, and any API that adds its own MIME metadata — which is exactly why this tool offers it as a separate output format.

The ~33% overhead, and when inlining helps or hurts

Base64’s 4-characters-per-3-bytes ratio means an encoded image is roughly 133% of its original size before compression. Gzip or Brotli on the server claws back part of that — Base64 output is repetitive enough to compress — but an already-compressed JPEG or WebP still ends up meaningfully larger over the wire than the same file served as binary. So inlining is never about saving bytes; it is about saving requests and files, and the trade only pays off in specific situations.

Inlining helps when the image is small and the request would have cost more than the payload: icons and logos of a few kilobytes, tiny blurred LQIP placeholders that must paint with the first byte of HTML, assets in a single-file document that has to work offline or as an attachment, and images inside JSON where there is no other option. For a 2 KB icon, one saved round trip easily outweighs ~700 bytes of encoding overhead.

Inlining hurts when the image is large or shared. A 500 KB photo becomes ~670 KB of text welded into your markup, inflating the document the browser must download and parse before it can render anything. The caching trade-off bites hardest: a normal image URL is fetched once and then served from the browser cache on every subsequent page, but an image inlined in HTML is re-downloaded with every single page view, because it is part of the page. (Inlining into an external CSS file is gentler — the stylesheet itself is cached — but every page that loads that CSS pays for every embedded image, used or not.) HTTP/2 and HTTP/3 also weakened the old argument for inlining: multiplexed connections make extra small requests far cheaper than they were under HTTP/1.1, so “fewer requests” alone no longer justifies embedding.

A practical rule of thumb: inline assets under roughly 5–10 KB that appear on every page or must live inside one file; serve everything else as a normal cached URL, ideally after running it through an image compressor first. This tool’s built-in compress and resize modes exist precisely so you can shrink the binary before the 33% surcharge is applied to it.

A note on SVG and PDF files

Raster images can safely be re-drawn on a canvas to compress, resize, or rotate them, but SVG and PDF are different animals: rasterising them would throw away the vector data that makes them sharp at any size. This tool therefore passes both formats through untouched — the bytes you drop in are exactly the bytes that get encoded, with the correct image/svg+xml or application/pdf MIME type set in the data URI. The processing modes simply do not apply to them, by design.

Two practical consequences follow. First, an SVG is usually the best candidate for inlining of any format here: it is already text, compresses extremely well, and a cleaned-up icon often encodes to under a kilobyte — run it through an SVG optimizer first and the data URI gets smaller still. Second, an encoded PDF is genuinely useful as a self-contained preview: the tool’s HTML output wraps it in an <embed type="application/pdf"> tag, which desktop browsers render with their built-in PDF viewer, so a small document can be dropped into a page with no hosted file behind it.

Output formats at a glance

Output format	What it produces	Where to paste it
Data URI	data:image/png;base64,iVBORw…	Anywhere a URL is accepted: src attributes, CSS url(), favicons, SVG <image>, canvas sources
Base64 string only	The raw encoded payload, no data: prefix	JSON bodies, API requests, config files, databases — anywhere the MIME type is declared separately
CSS background-image	background-image: url("data:…");	Straight into a stylesheet rule for icons, patterns, and decorative images
HTML <img> tag	<img src="data:…" alt="…" width="…" height="…">	Directly into markup; the pre-filled width/height prevent layout shift (PDFs become an <embed> tag instead)

The HTML output deserves a note: because the tool reads each image’s real pixel dimensions, the generated <img> tag ships with explicit width and height attributes. Browsers use those to reserve space before the image decodes, which avoids cumulative layout shift — a small detail that hand-written data-URI tags usually miss.

Encoding images to Base64 in JavaScript, Python, and the terminal

A visual converter is the fastest route for one-off snippets, but if encoding happens inside a build script, a backend, or a CI pipeline, you will want to do it in code. Every mainstream environment ships a one-liner:

Environment	Snippet	Notes
Browser (file)	reader.readAsDataURL(file)	FileReader returns a complete data URI, byte-identical to the source
Browser (canvas)	canvas.toDataURL("image/jpeg", 0.8)	Re-renders the pixels; accepts a format and a 0–1 quality argument
Node.js	fs.readFileSync("icon.png").toString("base64")	Raw string only — add the data:image/png;base64, prefix yourself
Python	base64.b64encode(f.read()).decode()	Open the file with "rb"; .decode() drops the bytes-literal b'' wrapper
macOS terminal	base64 -i icon.png	Prints one unbroken line to stdout
Linux terminal	base64 -w 0 icon.png	GNU base64 wraps lines at 76 characters unless you pass -w 0
PowerShell	[Convert]::ToBase64String([IO.File]::ReadAllBytes("icon.png"))	Works on Windows with no extra tooling

Two gotchas trip people up constantly. First, everything except readAsDataURL produces the bare Base64 string, so a snippet that “doesn’t render” usually just lacks its data: prefix — and the MIME type in that prefix must match the actual file, or the browser will refuse to decode it. Second, canvas.toDataURL() is not a lossless copy: it repaints the image and re-encodes it, so bytes change even at maximum quality, and a cross-origin image drawn without CORS headers “taints” the canvas and throws a SecurityError. When you need the original file preserved exactly, read the file directly instead of routing it through a canvas.

Using Base64 images in React, Vue, and modern bundlers

In JSX and Vue templates, a data URI drops straight into the usual binding: <img src={logoDataUri} alt="Logo" /> in React, or :src="logoDataUri" in Vue. Because the strings are long, keep them in their own module — export const logo = "data:image/png;base64,…" — and import them where needed, rather than pasting a wall of text into a component. In CSS-in-JS libraries such as styled-components or Emotion, the data URI goes inside url("…") in the template literal exactly as it would in a stylesheet.

Often, though, you should not hand-encode at all: bundlers already do it conditionally. Vite inlines any imported asset smaller than its assetsInlineLimit (4 KB by default) as a data URI automatically, and webpack does the same for imports under roughly 8 KB via asset modules (type: "asset"), emitting larger files as normal cached URLs. So inside a bundled app, import logo from "./logo.png" gives you the optimal behaviour for free. A pre-encoded string from this tool earns its keep where no bundler runs: static HTML, CMS body fields, Markdown that allows raw HTML, email builders, JSON fixtures, and quick CodePen-style demos.

Frequently asked questions

Is this free and private?

Yes. The converter is completely free, with no sign-up, watermarks, or usage caps, and it is fully private: files are read and encoded with your browser’s own FileReader and canvas APIs, on your device. No image, PDF, or generated string is ever transmitted to a server, and once the page has loaded the tool keeps working offline.

Is there a file size limit, and why is my output bigger than the original?

The tool imposes no hard limit — the practical ceiling is your browser’s memory, and modern browsers handle images of many megabytes without trouble. The output is always about 33% larger than the input because Base64 turns every 3 bytes into 4 text characters; that is inherent to the encoding, not a flaw in the file. If the result feels too heavy to inline, switch Processing to Compress or Resize and re-encode: shrinking the binary first shrinks the Base64 proportionally.

Can I convert HEIC photos from an iPhone?

Yes. HEIC and HEIF files are decoded to JPEG locally in your browser before encoding, so the resulting data URI uses a format every browser and email client can display. The conversion happens on your device like everything else — the photo is not uploaded to be transcoded.

What is the difference between a Base64 string and a data URI?

The Base64 string is just the encoded bytes. A data URI is that string plus an addressing wrapper — data:image/png;base64, — that tells a browser what the content is and how to decode it. Use the data URI when pasting into HTML, CSS, or anywhere a URL goes; use the bare string for JSON payloads and APIs that declare the content type themselves. If you paste a bare Base64 string where a URL is expected, nothing will render — the prefix is what makes it a valid source.

Does encoding change my image quality?

Not by itself. In the default Encode as uploaded mode, Base64 is a lossless re-labelling of the exact same bytes — decode the string and you get back a pixel-identical file. Quality only changes if you opt into it: the Compress and Convert modes re-render the image through a canvas at your chosen quality setting, and Resize resamples the pixels. If you need the original file preserved bit-for-bit, leave Processing on its default.

Can I encode several images at once?

Yes. Drop a whole batch and each file gets its own card with a thumbnail, dimensions, size readout, and Copy button. Copy all concatenates every snippet with a filename comment above each, and Download .txt saves the same output as a file — useful when you are embedding a full icon set into a stylesheet in one sitting.

Is there a maximum length for a Base64 data URI?

The data URI spec sets no limit, and modern engines are generous: Chromium and Firefox accept data URLs up to about 512 MB, and WebKit up to 2 GB. The practical constraints live elsewhere — browsers block navigating to a data: URL typed or pasted into the address bar (an anti-phishing measure), some HTML sanitizers strip very long attribute values, and a huge inline string still has to be parsed as part of your document. Staying in the kilobyte range is a habit worth keeping regardless of what the engine tolerates.

Why is my Base64 image blocked by Content-Security-Policy?

A CSP that defines img-src (or only default-src) blocks data: URLs unless the scheme is explicitly allowed, so inlined images vanish with a console violation error. The fix is to add the scheme to the image directive — img-src 'self' data: — which is considered low-risk. Do not add data: to script-src or default-src broadly, though: that would let an attacker with an injection point execute arbitrary code via a data URI.

Is Base64 encoding a form of encryption?

No. Base64 is an encoding, not encryption: it is a fixed, keyless, reversible mapping from bytes to text, and anyone can decode it instantly with standard tools. It provides zero confidentiality — never use it to hide credentials, API keys, or private images. If data needs protecting, encrypt it first; Base64’s only job is making binary safe to carry through text-based channels.

Will Google index an image embedded as Base64?

Effectively no. Google Images discovers and indexes images by their URL, and an inlined image has none — it is just text inside your page, so it cannot rank in image search or be linked, shared, or cached independently. The surrounding page still indexes normally. If an image matters for image-search traffic (product photos, portfolio work, infographics), serve it as a real hosted file with descriptive alt text, and reserve Base64 for decorative icons and UI chrome.

Related design tools

• Base64 to Image — the reverse tool: paste a Base64 string or data URI and decode it back into a downloadable image file.
• Image Compressor — shrink images before encoding so the 33% Base64 overhead applies to fewer bytes.
• Image Converter — convert between PNG, JPEG, WebP, and other formats with full control.
• SVG Optimizer — clean and minify SVG markup before inlining it in CSS or HTML.
• Favicon Generator — build a complete favicon set, another common destination for tiny inlined images.