Free Batch Image Converter

A Tour of the Major Image Formats

Image formats are not interchangeable. Each one was designed for a specific era, medium and trade-off, and choosing the wrong one (JPEG for a logo, PNG for a holiday photo) produces files that are either huge or ugly or both. The formats this converter understands span four decades and four distinct design philosophies. Knowing what each was built to do is the difference between an output you can ship and an output you have to redo.

JPEG (1992), the photograph format

The Joint Photographic Experts Group was formed in November 1986 in Parsippany, New Jersey, with members drawn from ISO TC97 SC2/WG8 and the CCITT SGVIII group. Six years of committee work later, the text of CCITT Recommendation T.81 was approved on 18 September 1992, with the identical text published as ISO/IEC International Standard 10918-1 in 1994. That two-document publication is the moment JPEG became the world's photograph format. The mathematical core is the discrete cosine transform applied to 8×8 pixel blocks: each block is decomposed into a sum of cosine waves, the high-frequency components human vision is least sensitive to are quantised more aggressively than the low-frequency ones the eye notices first. The user-facing "quality" slider is exactly this, a multiplier on the quantisation table. Higher quality means smaller divisors, more precision, larger files. Lower quality means more zeros after quantisation, better entropy coding and a smaller file at the cost of visible blocking and ringing artefacts. JPEG is lossy by design: there is no quality setting at which a JPEG round-trip is mathematically identical to its input. For photographs of natural scenes (faces, landscapes, food, anything with smooth gradients and continuous tone) this is irrelevant; the loss lives below the sensitivity threshold of human vision and the file is a fraction of the size a lossless format would produce. For graphics with hard edges, text, line art or large flat colour areas, JPEG is the wrong choice: the same DCT smears sharp edges with ringing artefacts ("mosquito noise") and blocky boundaries between 8×8 cells.

PNG (October 1996 / January 1997), the lossless graphics format

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 June 1987), the animation survivor and patent saga

Steve Wilhite, the engineering lead at CompuServe, introduced GIF on 15 June 1987 to solve a specific problem: how to share colour images across the slow modems of CompuServe's online service without the files swallowing the user's monthly allowance. His team chose the Lempel-Ziv-Welch (LZW) compression algorithm and capped the colour palette at 256 entries. What CompuServe did not know in 1987 was that LZW had been patented by the Sperry Corporation (later Unisys) in 1985. The patent issue erupted into public view in late 1994. Unisys announced in 1995 it would charge royalties on software using the algorithm (including GIF, TIFF and PDF) at rates of roughly 0.45% to 0.65% of revenue. The web's open-source community responded with two parallel actions: the "Burn All GIFs" campaign and the design of PNG, explicitly to be a patent-free GIF replacement. The Unisys US patent expired in June 2003; corresponding patents in other jurisdictions expired through 2004. By 2004, GIF was patent-unencumbered for the first time in its history. GIF survived because of one feature PNG (originally) did not have: animation. It supports a sequence of frames with per-frame delay timings and a transparent palette index, making it the lingua franca of looping reaction images and web banners. The 256-colour palette is a real limitation for photos, and the 1-bit transparency makes for ugly edges when overlaying on a coloured background, but for short looping animations of cartoon-style content GIF still wins on universal support.

BMP (May 1990) and TIFF (autumn 1986), the legacy holdouts

BMP (Bitmap, also called Windows Device Independent Bitmap) was incorporated into Windows 3.0, released on 22 May 1990, where it became the standard for bitmap storage in the Windows graphical environment. It is essentially uncompressed, the raw pixel array, optionally row-aligned to a 4-byte boundary, with a small header at the front. A 1920×1080 24-bit BMP is about 6.2 MB; the same image as a quality-85 JPEG might be 200 KB. BMP's role in 2026 is essentially as a legacy interchange format and the format Windows screenshots historically used. TIFF (Tagged Image File Format) was first published by Aldus Corporation in autumn 1986 (Revision 3.0); Revision 6.0 in June 1992 added CMYK and YCbCr colour and JPEG-in-TIFF. Adobe acquired Aldus in 1994 and now holds the copyright. TIFF is unique in being a container format rather than a single encoding scheme, a single TIFF file can hold multiple images (multi-page TIFF, common for fax and scanned book chapters), use any of several compression methods (none, LZW, ZIP, JPEG, CCITT Group 3/4 for fax) and store essentially arbitrary metadata via its tagged-field structure. This flexibility makes TIFF the default for prepress workflows, scanning and document archival; it is essentially never used for web images. Its presence in the input list is for users converting print-bound or scanned sources into web-friendly formats.

WebP (30 September 2010), the modern web format

Google announced WebP on 30 September 2010 as a new open format for lossy compressed true-colour graphics on the web, producing files smaller than JPEG at comparable quality. The format is based on the keyframe encoding from the VP8 video codec, which Google had acquired with the purchase of On2 Technologies. Initially WebP was lossy-only. On 18 November 2011, Google announced a lossless compression mode and support for transparency in both lossless and lossy modes; libwebp 0.2.0 reached a stable lossless implementation on 16 August 2012. Per Google's developer documentation: lossless WebP images are approximately 26% smaller than the same images in PNG, and lossy WebP images are 25-34% smaller than comparable JPEG at equivalent SSIM quality. These reductions are not magic, they come from a fundamentally newer codec design (predictive intra-frame coding, modern arithmetic entropy coding, smarter colour transforms) than the early-1990s baselines JPEG and PNG were designed against. Browser support was a slow build: Chrome 17 in February 2012 (lossy), Chrome 23 in November 2012 (lossless). Apple held out for the better part of a decade and finally added WebP support in Safari 14, which shipped with iOS 14 and macOS 11 Big Sur in September 2020. That September 2020 date is the moment WebP became practically usable as a primary web format without a JPEG fallback for iPhone users. Coverage today is approximately 97% of global traffic, WebP is no longer a "modern" format with caveats, it is a default.

Beyond WebP: AVIF (Feb 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 was released on 19 February 2019 by the Alliance for Open Media (AOMedia, a consortium of Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). It is the still-image profile of the AV1 video codec, built on the HEIF container, and is currently the best-compressing widely-deployed image format, at equivalent visual quality, AVIF files are typically 50% smaller than JPEG and 20-30% smaller than WebP. Browser support arrived in three waves: Chrome 85 (August 2020), Firefox 93 (October 2021), Safari with iOS 16 (September 2022) and macOS Ventura (October 2022). HEIC is the iPhone-default format since iOS 11 in 2017, the HEIF container with HEVC-compressed images, formally ISO/IEC 23008-12. Compression is excellent (typically 50% smaller than JPEG) but HEVC is patent-encumbered, which is why Chrome, Firefox and non-Apple Edge refuse to decode HEIC natively. JPEG XL (ISO/IEC 18181, 2022) is the technically excellent niche format, it can losslessly recompress existing JPEGs to ~20% smaller, supports HDR, wide gamut, animation and progressive decoding, and is patent-free. Chrome dropped its experimental flag on 31 October 2022 (the "Halloween decision"); Apple shipped Safari 17 in September 2023 with native JPEG XL across macOS Sonoma, iOS 17 and visionOS. The format is supported natively in Safari 17+, behind a flag in Firefox and Chrome 145 (February 2026), but ship-by-default for general traffic remains pending. This converter does not currently emit AVIF, HEIC or JPEG XL, they are listed here so you can decide whether to handle them upstream.

Picking the Right Output Format

The format-by-format history above is a tour. The practical question is shorter: given a particular image and a particular use, which output format is correct?

• Photographs with smooth gradients (people, food, landscapes, product shots): JPEG remains the safe answer for maximum compatibility, with quality 75-85. WebP at the same visual quality will be 25-34% smaller and is supported in 97% of browsers.
• Line art, screenshots with text, logos, charts, illustrations: PNG is the default. The hard edges and large flat-colour areas characteristic of these images are exactly what JPEG handles worst, DCT ringing artefacts smear the edges and make text look fuzzy. WebP lossless is approximately 26% smaller than PNG for the same content.
• Web optimisation for blog posts: WebP is the new default for new content; pair it with a JPEG fallback for legacy traffic if your audience requires it.
• Social-media variants: most platforms re-encode whatever you upload anyway, so the source format matters less than the source resolution and quality. Uploading a 4000×4000 PNG to Instagram saves no quality over uploading a 1080×1080 JPEG-quality-90, Instagram resamples and re-compresses both internally.
• Archival format normalisation: PNG (lossless) for graphics, TIFF for prepress and scanning archives where the workflow downstream expects TIFF. Avoid WebP and AVIF for long-term archival, both are still young, and decoder availability decades from now cannot be assumed with the same confidence as JPEG and PNG.
• iPhone export: convert HEIC to JPEG for maximum compatibility, to WebP for web use, or to AVIF for cutting-edge sites. The licensing complication around HEIC is precisely why a HEIC-to-anything-else converter is useful.

What the Quality Slider Actually Does

The quality slider runs from 10 to 100 in steps of 5. Behind that single number is a surprisingly nonlinear relationship between perceived quality and file size. For JPEG, the consensus across image-processing engineering is that quality 75-85 is the sweet spot. At quality 80, file size drops 70-90% from an uncompressed source with imperceptible visual difference at normal screen viewing distances. The drop-off between quality 80 and 85 is steep: a representative test image might go from 3.7 MB at quality 80 to 6 MB at quality 85, a near-doubling for no visible improvement on a phone or laptop screen. Quality 75 is where artefacts start to become detectable on close inspection of high-frequency detail (text edges, fine textures). Quality 90 and above is for archival JPEGs where file size is irrelevant. The default of 80 sits at the low end of the sweet spot, appropriate for batch web optimisation, where the goal is to ship as little data as possible while keeping images that look acceptable. For WebP, the canvas API's toBlob('image/webp') default is quality 0.80; WebP at quality 70 is generally as visually clean as JPEG at quality 80. For PNG, "quality" is a misnomer, PNG is always lossless on the pixel data. The slider in this tool has no effect when PNG is selected as the output format. The crucial lesson for batch processing: a single quality setting is rarely correct for every image in a mixed batch. A folder of 50 photos taken on the same camera in the same lighting can probably all save at JPEG quality 80 without loss. A folder mixing screenshots, photos, line art and logos cannot, a one-button "convert all to JPG-80" will turn the screenshots into illegible mosquito-noise. Split the input into separate batches when content varies.

Lossy vs Lossless, The Most Important Distinction

A lossless encoder guarantees the decoded output is bit-identical to the encoded input. PNG is lossless. WebP-lossless is lossless. TIFF (in its lossless modes) is lossless. The trade-off is file size: lossless encoders cannot exploit imperceptible perceptual differences and must preserve everything. A 1920×1080 photograph as lossless PNG might be 5 MB; the same photo as JPEG-quality-85 is 200 KB. The PNG is bit-perfect; the JPEG is visually equivalent. A lossy encoder discards information the human visual system is least likely to notice, high-frequency detail, fine chroma variation in saturated colours, the fourth significant figure of every gradient. JPEG, lossy WebP and lossy AVIF all do this. The implications for a batch converter are concrete: lossless to lossless (PNG to PNG, or PNG to WebP-lossless) is genuinely lossless across any number of conversions; lossy to lossy at the same quality (JPEG-85 to JPEG-85) is not lossless, each re-encode applies another quantisation step, repeat 10 times and the result is visibly degraded; lossy to lossless (JPEG to PNG) freezes the existing artefacts in place but does not re-degrade them; lossless to lossy introduces lossy compression at the moment of conversion and there is no way to recover the discarded detail later. Users often re-run a conversion expecting it to be a no-op. Outside of the lossless-to-lossless case, it is not.

EXIF, IPTC, XMP, and Why This Tool Strips Them

JPEG and HEIC files from cameras and phones carry an EXIF block, Exchangeable Image File Format metadata embedded in the image header. EXIF includes camera model, lens, exposure settings, date and time, software version, and most consequentially the GPS coordinates of where the photo was taken (if location services were on at capture time). IPTC metadata adds caption, byline, copyright and keywords. XMP, originally from Adobe, is an XML-based superset that subsumes the older formats and is what Lightroom and Photoshop use. The privacy implications are significant. A photo taken on an iPhone with location enabled embeds GPS coordinates accurate to within a few metres. Sharing it on a forum, in an email attachment, or via a personal blog can disclose the photographer's home address, their child's school, their workplace, their hiking route. Major social platforms (Facebook, Instagram, Twitter/X) strip EXIF on upload before serving the image to other users, but they read and store the original metadata themselves. Smaller forums, WordPress blogs, Discord, email clients and direct file transfers leave the EXIF intact. Re-encoding through the canvas API (the engine this tool uses) discards all EXIF, IPTC and XMP metadata by default. The output is a clean image with no embedded provenance, a privacy feature, and a side effect of the canvas pipeline (the canvas only stores pixel data; it has no notion of metadata to preserve). Users who want to preserve metadata (photographers archiving exposure data, content workflows where copyright must travel with the file) need a different tool, typically ImageMagick's convert or a dedicated EXIF-aware library. This converter cuts the other way: it is metadata-stripping by design, which is exactly what a privacy-conscious user wants when sending images to a forum where they do not want their GPS coordinates to follow.

Transparent Backgrounds, the PNG-to-JPEG Choice

PNG supports a per-pixel alpha channel: every pixel has an opacity from 0 (fully transparent) to 255 (fully opaque). JPEG has no alpha channel. Converting a PNG with transparency to JPEG forces a choice: what should the transparent pixels become? The canvas API's default is to composite against transparent black, so the resulting JPEG resolves transparent pixels to opaque black. A logo on a transparent background converted PNG-to-JPEG comes out with black corners around the logo, virtually never what the user wanted. The mitigation is to fill the canvas with a chosen background colour (white is the typical default) before drawing the image on top. Users who need to preserve transparency should choose PNG or WebP as the output format. WebP supports transparency in both lossless and lossy modes, which makes it the modern choice when the source has transparency and the destination needs to be efficient, a transparent-background PNG of 50 KB might become a transparent-background lossy WebP of 12 KB while preserving the alpha channel.

How the Conversion Runs in Your Browser

The "everything runs in your browser" claim rests on three Web Platform APIs that have only recently become powerful enough to make a batch image converter a credible client-side product. FileReader and Blob APIs: when you drop files into the upload zone, each File is a subclass of Blob exposing either readAsDataURL() (older callback) or file.arrayBuffer() (Promise-based). For images specifically, the simpler path is to construct a Blob URL with URL.createObjectURL(file) and assign it to a fresh Image element, letting the browser's built-in image decoder handle JPEG, PNG, GIF, WebP and BMP natively. The Canvas API: once an Image is loaded, the conversion is a two-step dance, draw with ctx.drawImage(img, 0, 0), then read the canvas back with canvas.toBlob(callback, type, quality). The type parameter is a MIME string ('image/png', 'image/jpeg', 'image/webp'); the quality parameter is a number between 0 and 1 for lossy formats. OffscreenCanvas and Web Workers: for large batches, doing all canvas work on the main thread blocks the UI. The modern solution is OffscreenCanvas, which exposes canvas operations in a worker context and is itself transferable to a Web Worker via postMessage without copying. The worker runs the decode-rasterise-encode pipeline in a separate thread, keeping the page responsive. Together these APIs make a 50-file batch run in seconds without blocking scrolling or button clicks. JSZip (a pure-JavaScript MIT-licensed library) handles the final ZIP packaging entirely in memory before the browser's save dialog fires. No upload, no server zip, no temporary file on disk. A decade ago a batch image converter that ran in the browser would have been a curiosity. WebAssembly performance, OffscreenCanvas parallelism, and modern phone RAM (6-12 GB) and core counts (6-8 CPUs) have reversed that picture. The privacy argument closes the case: server-side converters require uploading your images to a third-party machine, and even with a scrupulous deletion policy the upload itself is a network event that can be logged, intercepted or breached. A browser-only converter never sends a byte.

Frequently Asked Questions

What input formats can the converter actually handle?

JPEG, PNG, GIF, WebP and BMP work in every modern browser via the native image decoder. TIFF support depends on the browser, Safari decodes TIFF, Chrome and Firefox generally do not. HEIC works in Safari (because Apple licenses HEVC) but not in Chrome, Firefox or non-Apple Edge. The output formats are PNG, JPG and WebP, which the canvas API can emit in every modern browser. AVIF, HEIC and JPEG XL output is not currently supported because the canvas API does not expose those encoders without a WebAssembly codec.

What quality should I pick for JPG and WebP?

For JPEG: 75-85 is the sweet spot. The default of 80 is appropriate for most web optimisation work. For WebP: 75-80 produces files roughly 25-34% smaller than the equivalent JPEG at the same visual quality, because WebP's underlying VP8 codec is more efficient at the low end of the quality scale. Quality 90+ is reserved for archival images where file size is irrelevant. Below 75 you start to see DCT ringing artefacts on the JPEG side and slight blur on the WebP side. PNG is lossless, the quality slider has no effect on PNG output.

Can I download all the converted files at once?

Yes. After conversion, the "Download All as ZIP" button packages every output into a single ZIP archive built entirely in your browser via JSZip (a pure-JavaScript MIT-licensed library). The archive is assembled in memory and the browser's save dialog fires once. No server-side zip, no temporary file on disk, no upload. Per-file download links are also available for selective grabs.

Why is the limit 50 files per batch?

It is a memory ceiling. Every image has to be decoded into RAM as raw pixel data before the canvas can re-encode it. A 12-megapixel iPhone photo decodes to about 36 MB of pixel data (12 million pixels × 3 bytes RGB, or 4 bytes RGBA). 50 of those at once is 1.8 GB of working memory. Most laptops handle that comfortably; older phones do not. The 50-file cap keeps the page predictable across devices. For larger batches, run the tool in rounds, say, 50 files, download, clear, drop another 50.

Is there a per-file size limit?

No hard cap, the limit is your device's available memory. A single 50 MP image decodes to about 150 MB of pixel data, which works on a desktop but will struggle on an older phone. As a rule of thumb, files under 10 MB convert smoothly on essentially any device; files over 50 MB will slow down or fail on lower-end mobile. If a conversion freezes, refresh the page and try the file in a smaller batch.

Does the converter strip EXIF metadata?

Yes, by design. The canvas re-encoding pipeline only stores pixel data, so EXIF, IPTC and XMP metadata blocks (camera model, exposure settings, GPS coordinates, copyright tags, edit history) do not survive the round-trip. The output is a clean image with no embedded provenance, which is a privacy win when you are sharing photos to forums or email contacts where you do not want GPS coordinates to follow. If you need metadata preserved (photographers archiving exposure data, content workflows requiring copyright tags), this is the wrong tool, use ImageMagick's convert or a dedicated EXIF-aware library that explicitly preserves metadata.

What happens to transparent backgrounds when I convert PNG to JPG?

JPEG has no alpha channel, so transparent pixels in the source PNG have to become some opaque colour in the JPEG output. The canvas-default behaviour is to composite against a coloured background (typically white). A logo on a transparent PNG background converted to JPEG will lose the transparency and pick up the background fill. If transparency matters, choose PNG or WebP as the output format, both preserve alpha. WebP-lossy preserves transparency at dramatically smaller file sizes than PNG and is the modern choice for transparent web graphics.

Are my images uploaded anywhere?

No. Every step (file selection, decode, canvas re-encode, ZIP packaging, download) runs entirely in your browser via JavaScript. There is no server-side processing. You can verify by opening your browser's DevTools Network tab while you convert: there are no outbound requests carrying image data. The page is safe for sensitive screenshots, document scans, personal photos with location metadata, or anything else you would not want copied onto a stranger's hard drive.

Related Tools