Image to Base64

One page loads 26 tools that share a single upload queue: Image to Base64 and back, flip, rotate, enlarge, crop, resize, compress, a general converter, a JPG converter, and 17 named format pairs including JPG to PNG, WebP to JPG, PNG to WebP and PNG to ICO. Switching tools keeps the images already dropped in and clears only the previous output and status, so you can resize, then compress, then convert the same batch without re-uploading anything. The input filter accepts seven MIME types — image/jpeg, image/png, image/webp, image/gif, image/bmp, image/x-icon and image/svg+xml — and quietly drops anything else at selection time, with an error toast if nothing in your selection qualifies.

A checkbox labelled 'Use high-quality server processing (Sharp)' decides where pixels are touched, and it starts ticked. Leave it on and the file is POSTed to /api/image, processed in memory by Sharp and returned as a data URL in the JSON response; nothing is written to disk and no file survives the request. Untick it and every operation runs on a CanvasRenderingContext2D inside your tab, with no network request at all. Image to Base64 and Base64 to Image ignore the toggle and always run locally. The paths differ in output: Sharp upscales with a Lanczos3 kernel and encodes JPEG through mozjpeg, while canvas uses imageSmoothingQuality 'high' and whatever encoder the browser ships. Use the client path for anything confidential and Sharp when fidelity or exact dimensions matter.

Image to Base64 returns the complete data URL — data:image/png;base64,… — ready to paste into an img src, a CSS background-image or a JSON payload. It reads the file with FileReader.readAsDataURL, so the bytes never leave the page even when the Sharp checkbox is ticked, and a copy button writes the string straight to the clipboard. Base64 inflates payloads by roughly 33%, four output characters for every three input bytes, which is why inlining pays for small icons and sprites but not for photographs. Base64 to Image runs the reverse: paste a string with or without the data: prefix, a missing prefix is assumed to be data:image/png;base64, and the string is validated with atob before it is decoded and previewed.

PNG to ICO and JPG to ICO do not simply rename a PNG. On download the browser builds a genuine ICO container in an ArrayBuffer: a 6-byte header holding the reserved field, type 1 and image count, then one 16-byte directory entry per size recording width, height, colour planes, 32 bits per pixel, byte length and offset, followed by the image payloads. Three entries are written — 16×16, 32×32 and 48×48 — each stored as PNG data, the encoding Windows has accepted inside ICO since Vista. That is the classic favicon.ico set, and because the entries are 32-bit they keep the alpha channel. Browsers pick whichever entry matches the surface, so one file covers tab icons, bookmarks and desktop shortcuts.

24 of the 26 tools take multiple files; only Image Cropper and Base64 to Image are single-file, because both depend on one specific set of coordinates or one pasted string. Drop a folder's worth and each image carries its own status — pending, processing, done or error — so one corrupt file marks itself failed instead of killing the run. The input grid previews the first six thumbnails with pixel dimensions and a '+N more' tile; the output grid shows the first four with resulting dimensions and byte size. Download All fires the saves at 300 ms intervals so browsers do not block them. The resizer's presets are Instagram Post 1080×1080, Instagram Story 1080×1920, Facebook Cover 820×312, Twitter Header 1500×500, favicon 16, 32 and 48, and a 64×64 app icon — clicking one also unticks the aspect-ratio lock.

SVG to PNG, JPG and WebP read the file as text, wrap it in a base64 data URL and rasterise it through canvas at its intrinsic size, so anything the file references externally — remote fonts, linked images — will not appear in the output, and markup containing characters outside Latin-1 fails the base64 step outright. Going the other way, PNG to SVG and JPG to SVG with server processing switched off run an actual trace: pixels are greyscaled as (R+G+B)/3, thresholded at 128, flood-filled into connected components and emitted as horizontal run rectangles in path data over a white background. The result is a monochrome silhouette, not a colour vectorisation. Leave Sharp on for SVG output and you get the raster embedded inside an svg wrapper instead — convenient for scaling, but not vector geometry.

Only if you leave the Sharp checkbox ticked, which is the default. With it on, the file is POSTed to /api/image, held in a Node Buffer, processed in memory by Sharp and returned as a base64 data URL in the JSON response — the route never writes to disk and keeps nothing after it replies. Untick 'Use high-quality server processing (Sharp)' and every operation runs on a canvas element inside your tab with no network request at all. Image to Base64 always runs locally whatever the checkbox says.

Seven input MIME types pass the filter: image/jpeg, image/png, image/webp, image/gif, image/bmp, image/x-icon and image/svg+xml. Anything else is dropped silently when you select it, and if nothing in your selection qualifies you get an error toast instead. The converter's output picker offers PNG, JPEG, WebP, GIF, BMP, ICO and SVG, and 17 named tools cover the common pairs: JPG to PNG, PNG to JPG, WebP to JPG, WebP to PNG, PNG to WebP, JPG to WebP, PNG to BMP, JPG to BMP, JPG to GIF, PNG to ICO, JPG to ICO, SVG to PNG, JPG or WebP, and PNG or JPG to SVG.

Choose PNG to ICO, drop a square image — 256×256 or larger keeps the 48×48 entry crisp — press Process, then Download. The download step builds the ICO container itself in an ArrayBuffer: a 6-byte header holding the reserved field, type 1 and image count, then three 16-byte directory entries recording width, height, one colour plane, 32 bits per pixel, byte length and offset, followed by three PNG payloads at 16×16, 32×32 and 48×48. Non-square sources are scaled into the square, not cropped. Save the file as favicon.ico in your site root.

Base64 encodes three bytes as four ASCII characters, so the payload is roughly 33% larger than the binary file, plus 22 characters for the data:image/png;base64, prefix. A 12 KB PNG becomes about 16 KB of text. That trade pays off for small icons, sprites and inline email assets where you save an HTTP round trip, but it is a poor deal for photographs: base64 text derived from already-compressed image data gzips badly, so most of the inflation survives transfer encoding rather than being squeezed back out.

24 of the 26 tools accept multiple files — everything except Image Cropper and Base64 to Image, both of which work from a single image's coordinates or a single pasted string. Drop or select as many as you like; the panel previews the first six with a '+N more' tile, and each file carries its own pending, processing, done or error state, so one unreadable image marks itself failed instead of aborting the run. Download All then fires the saves sequentially with a 300 ms gap so the browser does not block them as a popup burst.

JPEG and BMP carry no alpha channel, so transparent pixels have to become something. Both paths flatten onto white first: the canvas path fills #FFFFFF across the bitmap before drawing, and the Sharp path calls flatten with r:255, g:255, b:255. That is exactly why a logo with a transparent background shows a white box after PNG to JPG. If transparency matters, convert to PNG or WebP instead — both keep alpha — or to ICO, whose 32-bit-per-pixel entries store PNG data and preserve it too.

It runs from 10 to 100 and means something different per format. On the server path JPEG goes through Sharp's mozjpeg encoder at that value and WebP takes it directly, while PNG converts it to a zlib compression level of floor((100 − quality) / 10) — so a lower number means heavier lossless squeezing, and quality 100 gives level 0, the largest PNG. On the client path the value is divided by 100 and passed as the second argument to canvas.toDataURL. Presets sit at 50, 70, 85 and 100; the compressor swaps in 30, 50, 70 and 85 and defaults to 60. The slider is not rendered for Flip, Rotate or the two Base64 tools.

Only with the Sharp checkbox unticked, and only as a monochrome trace. The client path greyscales each pixel as (R+G+B)/3, thresholds it at 128, flood-fills the connected dark regions and emits each as horizontal one-pixel-tall run rectangles in path data, over an opaque white background rect. That is a silhouette, not a colour vectorisation, and because it walks every pixel it slows down and inflates the file on detailed sources — keep the input small. Leave Sharp on and SVG output is instead the raster embedded as a base64 image element inside an svg wrapper.

Any angle that is not a multiple of 180° needs a bigger canvas to hold the corners, so output is sized to the rotated bounding box: floor(width × |cos θ| + height × |sin θ|) for the new width and floor(height × |cos θ| + width × |sin θ|) for the new height. A 400×300 image rotated 45° becomes 494×494, with the new corner area transparent — the canvas path writes PNG, and the Sharp path rotates against a fully transparent background. The slider covers 0–360° continuously, with one-click buttons at 90°, 180° and 270°.

Neither. Every path here handles a single frame, so an animated GIF loses its animation. Real GIF encoding happens only on the server path, where Sharp calls .gif(). BMP has no encoder at either end: the API route's output switch has no BMP case and falls through to PNG, and canvas toDataURL returns image/png whenever the requested type is unsupported, which the HTML specification requires. So PNG to BMP and JPG to BMP hand you PNG bytes carrying a .bmp extension — fine in most viewers, wrong if something inspects the file header.

Image Compressor always re-encodes to JPEG, at quality 60 by default, with presets at 30, 50, 70 and 85. A 3 MB camera JPEG at quality 60 typically lands between 200 and 400 KB. The panel prints the original size, the compressed size and the percentage saved for the first image in the queue after each run, so you can nudge the slider and re-run until the number is acceptable. One caveat: with server processing on those bytes are the real encoded buffer, while with it off the size is measured from the data-URL string and reads roughly a third high.

Because the two paths fit differently. Untick 'Maintain aspect ratio' and the server path resizes with Sharp's fit:'fill', giving the exact box you typed. The canvas path always fits inside those numbers instead — it scales by the smaller of width÷original-width and height÷original-height, so a 1600×900 photo asked for 1080×1080 comes out 1080×607. Clicking a preset such as Instagram Post 1080×1080 also unticks the aspect-ratio lock for you. If the output must be exactly the preset dimensions, leave the Sharp checkbox ticked.