Attēls uz Base64

Convert image to Base64 online

This free Image to Base64 converter turns any image into a Base64 string or data URI right in your browser — no upload, no sign-up, no software to install. Drop a file, click to browse, paste from your clipboard, or load an image from a URL, and you instantly get a copy-ready data:image/…;base64,… string plus matching CSS, HTML, and Markdown snippets.

It works both ways: encode an image to Base64, or switch tabs to decode a Base64 string back into a viewable, downloadable image. Because the whole tool runs client-side using the browser's FileReader and Canvas APIs, your images never leave your device — making it safe for private logos, screenshots, and unpublished artwork. This is in contrast to popular alternatives like base64.guru and base64encoder.io, which upload your images to remote servers for processing.

How to convert an image to Base64

1. Drag and drop your image onto the upload box, click to choose a file, paste an image, or enter an image URL. 2. The tool reads the file locally and generates the Base64 data URI immediately, showing the original size, the encoded size, and the image's dimensions. 3. Copy the output in the format you need — raw Base64, a full data URI, a CSS background-image rule, an HTML <img> tag, or Markdown — or download it as a .txt file.

To go the other direction, open the Base64 → Image tab, paste a data URI or raw Base64 string, and the tool decodes it, previews the image, and offers a one-click download with the correct file extension. The entire round-trip — encode then decode — verifies that your Base64 output is valid and complete.

Embed Base64 images in HTML, CSS, Markdown, and email

A Base64 data URI lets you embed an image directly inside your code as text instead of linking to a separate file. In HTML, drop the string into an image tag's src; in CSS, place it inside url("…") for a background; in Markdown, use the image syntax ![alt](data:image/png;base64,…). This removes an extra HTTP request, which is handy for small icons, single-file pages, and offline demos.

Inlining is especially common in HTML email, where bundling images into the message avoids broken links and "download images" prompts — though some clients such as Outlook may block Base64 images, so always test first. Developers also store small Base64 images in JSON payloads, databases, and configuration files where a binary file would be awkward.

Image to Base64 in JavaScript and Python

In JavaScript, the browser does the work for you: const r = new FileReader(); r.onload = () => use(r.result); r.readAsDataURL(file); gives you the complete data URI. In React, wrap this in an onChange handler on a file input; in Next.js, you can also encode images server-side using Node's Buffer.from(bytes).toString('base64'). This converter uses exactly the FileReader API, so what you copy matches what you'd get in your own code.

In Python, encode the raw bytes with the base64 module: base64.b64encode(open('image.png','rb').read()).decode(), then prefix it with data:image/png;base64,. With Pillow (PIL), save the image to a BytesIO buffer first and Base64-encode the buffer. Use this tool to verify your output quickly without running a script.

Competitor comparison: UtiloKit vs base64.guru, base64encoder.io, browserling

base64.guru is one of the most-visited Base64 tools online, but it uploads your images to their server — a significant privacy concern for logos, product mockups, or confidential documents. base64encoder.io works similarly, processing files server-side. Browserling's image-to-Base64 tool is also server-side and limits free users by file size (75 MB cap on the free tier) and the number of daily conversions.

UtiloKit runs entirely in your browser with no file size restrictions beyond what your device's RAM can handle, no daily limits, and no data leaving your machine. You get the same output — a valid data URI — with the extra snippets (CSS, HTML, Markdown) that the above tools don't provide. For teams working with proprietary assets, the privacy difference is significant: no server ever sees your image.

When to use Base64 — and when not to

Base64 is perfect for tiny, rarely-changing assets, but it isn't free: the encoded text is roughly 33% larger than the original file, and an inlined image can't be cached or lazy-loaded on its own. For large photos or images reused across many pages, a normal image file (and HTTP caching) will load faster. As a rule of thumb, inline small icons and logos under ~10 KB, and keep everything bigger as standard files.

Whether you're encoding an image to a Base64 string, decoding Base64 back to an image, or just inspecting a data URI, this tool is fast, private, and completely free — every conversion stays on your device. Works on iPhone, iPad, Android, and all modern desktop browsers with no installation required.

How Base64 encoding works

Base64 encoding takes binary data in groups of 3 bytes (24 bits) and re-encodes each group as 4 ASCII characters — 6 bits per character — drawn from a 64-character alphabet: uppercase A–Z, lowercase a–z, digits 0–9, plus + and /. When the input length isn't a multiple of 3, one or two = padding characters are appended so the output is always a multiple of 4 characters. This mechanical process is defined in RFC 4648, the same standard used by TLS, MIME, and HTTP Basic authentication.

The technique was invented to solve a concrete problem: early SMTP email servers were designed to carry 7-bit ASCII text only. Binary files such as images contain all 256 byte values, many of which SMTP routers silently mangled or stripped. Base64 converts those arbitrary bytes into a subset of printable ASCII that every mail relay passes through untouched. The cost is a predictable 33% size increase — every 3 bytes of binary become 4 characters, so a 12 KB PNG encodes to roughly 16 KB of text.

A closely related variant called Base64URL (also defined in RFC 4648) replaces + with - and / with _, and omits the trailing = padding. This makes the output safe for use in URLs and filenames without percent-encoding. JWT tokens and many web APIs use Base64URL; standard Base64 (with + and /) is used inside data URIs because the , delimiter already separates it from the preceding MIME type declaration.

Data URIs — the complete specification

A data URI is defined by RFC 2397 and follows the format data:[<mediatype>][;base64],<data>. The mediatype is a standard MIME type such as image/png, image/jpeg, image/svg+xml, or image/webp. If omitted it defaults to text/plain;charset=US-ASCII. For text-based data you can also specify a charset — for example data:text/html;charset=utf-8,<h1>Hello</h1> — which allows entire HTML fragments or CSS stylesheets to be embedded as data URIs.

SVG is a special case worth knowing: because SVG is XML-based text, it can be embedded in a data URI without Base64 encoding at all, using URL encoding instead — data:image/svg+xml,%3Csvg …%3E. URL-encoded SVG is typically smaller than Base64-encoded SVG because Base64 adds 33% overhead whereas URL encoding only expands special characters. Modern browsers accept both forms, but Base64 SVG is universally supported, including in older email clients and Internet Explorer.

Once a browser encounters a data URI in an img src, a CSS url(), or an iframe src, it treats it identically to a resource fetched from an external URL: it parses the MIME type, decodes the data, and passes the result to the appropriate renderer. No additional network request is made. The browser's rendering pipeline sees only an already-decoded byte stream — the fact that it came from a data URI rather than an HTTP response is transparent to the downstream parsing and display engine.

Images in email clients and the data URI problem

Email clients have widely divergent image-handling behavior that directly affects how you should embed images. Outlook 2007–2019 uses Microsoft Word's rendering engine rather than a real browser engine, and that engine does not support data URIs — a Base64 inline image simply does not render. Gmail proxies externally linked images through Google's own servers (to strip tracking pixels), but does support inline Base64 images in HTML email. Apple Mail supports data URIs fully, as do most modern webmail clients.

The recommended approach for reliable HTML email is to use Content-ID (CID) embedding — attaching images as MIME parts and referencing them with src="cid:image1" — rather than data URIs. CID images work in Outlook because the email client's renderer fetches them from the MIME attachment rather than from a URL or a decoded data string. However, if your email is a single-file HTML document (a receipt, a report export, a preview) rather than a multipart MIME message, Base64 is still the only way to bundle images into that single file.

The practical recommendation: use Base64 inline images in transactional single-file HTML and self-contained reports where you control how the file is opened, and test on Outlook if your audience uses it. For bulk email campaigns sent through providers like Mailchimp or SendGrid, host images on a CDN and link to them — the CID approach is impractical at scale and most ESPs rewrite image links anyway for tracking and proxy purposes.

Performance implications and browser limits

During the HTTP/1.1 era, browsers limited concurrent connections to a single domain (typically 6), so every additional image file consumed a precious connection slot and added TCP handshake and DNS lookup latency. Inlining small images as data URIs eliminated those round-trips entirely, which was a measurable win for icon-heavy interfaces. That rationale weakened significantly with HTTP/2, which multiplexes all requests over a single connection — the per-file overhead that made many small external images slow essentially disappears, making the connection-savings argument for data URIs far less compelling in modern stacks.

Browser limits on data URI length have historically varied: Internet Explorer 8 capped data URIs at 32 KB, making it incompatible with anything beyond small icons. Modern browsers — Chrome, Firefox, Safari, Edge — impose no documented practical limit, but extremely long data URIs (multi-megabyte images) can still affect HTML parser performance because the entire string must be read and decoded synchronously when the parser encounters it. More importantly, because a data URI is part of the HTML or CSS document, it is not cached independently: every page load re-transmits and re-decodes the image, even if nothing about it changed.

The widely accepted performance guideline is to inline only images below roughly 4 KB — the threshold at which the HTTP request overhead (TCP round-trip, headers, server processing time) outweighs the 33% Base64 size penalty. Above that threshold, an external image file served with a long-lived Cache-Control: max-age header will almost always load faster on repeat visits. Build tools such as webpack, Vite, and Next.js apply exactly this heuristic: they automatically inline assets below their configured limit (often 4–8 KB) and emit separate files for anything larger.