Free bulk image converter in the browser

Overview

This app is built for a very practical workflow: you have one image or many images on your device, you want to convert them to another format, you may want to shrink them proportionally, and you want the result immediately without sending files to a remote server.

The current version accepts mixed local inputs in JPG, PNG, BMP, WEBP, and AVIF. It converts the whole loaded batch to one selected output format at a time. The output format buttons are ordered in a practical progression: PNG for lossless output, JPG with MozJPEG for good compatibility and good compression, WEBP for better compression in many normal web cases, and AVIF for the strongest compression efficiency when you want very small files and modern-format output.

The app is aimed at publishers, webmasters, designers, affiliates, content teams, bloggers, and anyone preparing images for websites, social content, documentation, or asset libraries. It is also useful for mixed folders where images have different orientations, resolutions, and original file types.

How to use the app

Step 1. Load one or more images

Click the file input area or drag and drop files into the app. You can load a single image or a large mixed batch. The app will show compact original previews and basic metadata for each file:

• original filename
• detected format
• file size
• pixel resolution

This compact layout matters on mobile and in long batches, because the goal is to keep many items visible without making the page excessively long.

Step 2. Open optional settings only if you need them

The settings area is intentionally collapsed by default. Many users only want direct format conversion and should not be forced to think about resize or naming options first. Inside the settings section, you can control three main things:

1. Longer-axis resize limit. This is optional. If enabled, the app proportionally reduces each image so its longer side fits the maximum you set. Landscape images use width as the longer side, portrait images use height, and square images use the same value for both.
2. Quality slider. This affects JPG, WEBP, and AVIF output. PNG ignores this slider because the current PNG output path is treated as lossless output.
3. Filename suffix. This is optional. If you enter a suffix like -1920, then a file such as picture.png can become picture-1920.jpg after conversion.

Step 3. Click a Convert button

Conversion only begins when you click one of the output buttons. The app does not auto-convert while you move the quality slider or change resize settings. This is intentional. It avoids unnecessary CPU usage and gives the user a clear moment where processing starts.

The buttons are labeled clearly to show that they start an action:

Convert to PNG Convert to JPG Convert to WEBP Convert to AVIF

Step 4. Review the results

For each original file, the converted result appears beside it. This makes batch comparison much easier than using one large result block for the entire run. Each result card shows:

• result preview
• output filename
• output format
• output file size
• output resolution
• quality value when relevant

Clicking a preview opens a larger in-page lightbox, so the user can inspect the image without leaving the tool.

Step 5. Download one file or the whole batch

You can download converted files individually, download all of them separately, or download all converted files as one ZIP archive. ZIP download is the most convenient option for larger batches because it reduces click count and keeps the exported set together.

What the app can do

Supported input and output formats

Image format choice is not only a technical detail. It affects page weight, visual quality, transparency support, download size, editing workflow, and long-term compatibility. This section explains the formats that matter in the current app.

PNG

PNG is a lossless raster image format. It is a very strong choice for graphics, screenshots, UI elements, logos, icons, text-heavy images, and images that need transparent background. PNG is usually not the smallest format for photographs, but it is safe and reliable when you need exact pixel preservation.

A common misunderstanding is that PNG means no compression. That is not technically correct. PNG does use compression, but it is lossless compression. In practical user terms, this means the current app does not expose a quality slider for PNG output because there is no lossy quality trade-off in the current PNG path.

JPG and JPEG

JPG and JPEG refer to the same family of lossy image format. JPEG remains one of the most widely compatible image formats in the world. It is especially strong for photographs and other continuous-tone images where small quality loss is acceptable in exchange for much smaller files.

In this app, JPG output is encoded through MozJPEG rather than a basic browser encoder. That matters because MozJPEG is designed to produce smaller JPEG files at similar visual quality compared with simpler encoding workflows.

WEBP

WEBP is a modern web-focused image format. It supports both lossy and lossless compression and also supports transparency. In many ordinary website situations, WEBP gives smaller files than older combinations such as JPG for photos and PNG for transparent assets. That makes it a strong practical default for general website publishing.

AVIF

AVIF is based on the AV1 image file format and is generally the most compression-efficient output option in this app. It can often deliver very small files at very good visual quality. The trade-off is that encoding is usually slower than JPG or WEBP, and some workflows still prefer the broader editing compatibility of older formats.

BMP

BMP is accepted as an input format, but not offered as an output format in the current interface. BMP files are often large and are mainly useful as source material or compatibility input. In most website and publishing workflows, users will convert BMP to JPG, WEBP, AVIF, or PNG.

Which output format should you choose

There is no single best format for every case. The right answer depends on the type of image, the publication channel, and whether compatibility or smallest file size matters more.

Choose PNG when

• you need exact pixel preservation
• the image has logos, icons, interface elements, text, or sharp edges
• you need transparent background and want a safe lossless choice
• file size is less important than visual fidelity

Choose JPG when

• the image is mainly photographic
• you want very broad compatibility
• you need a familiar output for editors, CMS tools, or older workflows
• you want a good balance of quality and file size

Choose WEBP when

• the image is meant for the web
• you want better compression than older common web formats in many cases
• you want transparency support in a more compact format
• you are preparing assets for modern websites

Choose AVIF when

• smallest possible file size is a priority
• you are optimizing large batches for modern delivery
• slower encoding is acceptable
• you are comfortable using a newer format in your workflow

Resize and quality settings explained

Longer-axis resize

Bulk batches often contain a mixture of portrait, landscape, and square images. That is why the app uses a single maximum for the longer side instead of independent width and height boxes in the bulk workflow. This is much simpler for real production use.

Example: if you enter 1920 as the maximum longer axis, then a 4000 by 3000 landscape image becomes 1920 by 1440, and a 3000 by 4000 portrait image becomes 1440 by 1920. A square 3000 by 3000 image becomes 1920 by 1920.

The current bulk logic only downscales. If the source image is already smaller than your limit, the app keeps the original size instead of upscaling it.

Quality slider

The quality slider is shared across JPG, WEBP, and AVIF in the current interface. Lower values usually mean smaller files and more aggressive compression. Higher values usually mean larger files and less visible loss.

PNG ignores this slider in the current version. This is expected.

Filename suffix

Suffix is useful when you want to keep the original base name but clearly mark the converted or resized variant. For example:

• banner.png to banner-1920.webp
• logo.avif to logo-web.jpg
• screenshot.bmp to screenshot-small.png

If the suffix field is empty, the app keeps the original base filename and only changes the extension to match the chosen output format.

Privacy, data handling, and limitations

No server-side processing

The app is designed so that the user selects local files, the browser decodes them, the app optionally resizes them, the selected encoder generates new output, and the user downloads the results. There is no required upload path in the normal conversion flow.

No ad or account layer

There is no registration requirement, no paywall, and no ad layer in the tool itself. This keeps the workflow simpler and matches the open-source utility purpose of the project.

Metadata expectations

Users should not assume that original image metadata is preserved. The app decodes source images to pixel data and re-encodes fresh outputs. In practical terms, this means EXIF, camera metadata, embedded profiles, or other source-container information may be lost or changed in the current implementation.

Browser limits

Because the work happens in the browser, very large images or very large batches can use significant memory and CPU time. Also, input decode support depends partly on the user browser. The app accepts AVIF and WEBP input, but whether a specific browser can open every source file still depends on that browser's image decoding capabilities.

Why the debug log exists

The debug log is collapsed and visually quiet, but still included because it is valuable in real open-source maintenance. It helps developers and bug reporters see which step failed, which output format was selected, and what the app tried to do.

Developer documentation and architecture

High-level architecture

This project is a pure client-side web app. It uses plain HTML, custom CSS, and vanilla JavaScript. There is no framework runtime, no backend API, and no package manager dependency at runtime. All third-party codec assets are self-hosted under a local assets path.

Why this app uses jSquash-derived codecs instead of FFmpeg

FFmpeg is excellent as a broad media engine, but image conversion in the browser is usually a better fit for dedicated image codecs. This app follows the same general direction that made Squoosh effective: specialized image codecs compiled to WebAssembly, with browser-native decode and a focused image pipeline.

In practical terms, the app uses jSquash packages as browser-friendly wrappers around proven codec implementations. jSquash itself is derived from the Squoosh app ecosystem, which is why it fits this project naturally.

Module loading strategy

Encoder modules are not hard-loaded up front. They are loaded on demand when the user clicks a specific Convert button. This keeps initial startup cleaner and avoids doing unnecessary work before a format is selected.

When the user chooses a format, the app uses dynamic import() to load the matching encoder module. The loaded encoder is then cached in memory inside a Map so it does not need to be imported repeatedly during the same session.

Why an import map is used

The AVIF path depends on wasm-feature-detect. Because the app is self-hosted and does not hotlink third-party files from a CDN, the app defines an import map in the HTML and points that package name to the locally hosted ESM file.

Decode path

Input files are first decoded by the browser. The app tries createImageBitmap() first for metadata reads and pixel decode. If that fails, it falls back to a normal image element backed by an object URL. This gives the app a more robust path across browsers and file types.

Resize path

Resize is done through a canvas pipeline. The app converts the source into ImageData, calculates target dimensions based on the optional longer-axis limit, and redraws to canvas with image smoothing enabled. The resize algorithm is intentionally simple and predictable. It always preserves aspect ratio in the batch workflow.

Encode path

After resize, the app passes the resulting ImageData into the selected encoder. Encoder options are built by format. In the current UI, JPG, WEBP, and AVIF expose a shared quality setting, while PNG uses an empty options object for lossless-oriented output.

Batch state model

The app keeps a central state object for the loaded source items, encoder cache, current batch format, ZIP URL, and CRC table used by the ZIP builder. Each input item stores its file reference, original preview URL, metadata, and current result object.

Preview strategy

Object URLs are used for both source previews and converted output previews. Clicking a preview opens a lightbox inside the current page. This gives the user a much more useful inspection workflow than forcing a new tab or external file open.

ZIP generation without an external ZIP library

The ZIP download feature is implemented directly in the app. The JavaScript builds a simple ZIP file structure in memory, writes local headers and central directory entries, calculates CRC32 checksums, and exports the result as a Blob. This keeps the project dependency surface smaller.

The current ZIP builder uses the store method rather than an additional compression stage. That is appropriate here because the image outputs are already compressed by their own encoders. Re-compressing them inside ZIP would often add little value while making the code more complex.

Memory management

The app revokes object URLs when batch data is cleared or replaced. This is important in a browser-side media tool because many previews and outputs can otherwise keep memory alive longer than necessary.

Why settings do not auto-convert

Auto-converting on every slider or resize change would be expensive, especially for AVIF and larger batches. It would also make the UI harder to understand. The current design keeps settings as passive inputs and conversion as an explicit action.

Suggested future developer additions

• separate effort or speed controls for AVIF and WEBP
• lossless WEBP toggle
• PNG optimization options if a dedicated PNG optimizer is added later
• metadata strip or preserve options, where technically possible
• drag-to-reorder batches
• folder upload where browser support allows it
• worker-based off-main-thread processing for larger jobs

Libraries, upstream projects, and licensing

This app deliberately self-hosts codec assets instead of loading them from third-party servers at runtime. That is important both for privacy and for reliable long-term deployment.

Main upstream projects

• CasinoLove Image Converter Bulk - this project's public repository
• jSquash - browser-focused WebAssembly image codecs derived from Squoosh
• Squoosh - the broader image compression app ecosystem that inspired the codec direction
• wasm-feature-detect - WebAssembly feature detection used by the AVIF path
• MozJPEG - JPEG encoder used for the JPG output path
• libwebp - WebP encoder and decoder project
• libavif - AVIF encode and decode library

Package paths used in the current app

FAQ

Does the app upload my images to a server?

No. The intended workflow is local browser processing only.

Can I load many files at once?

Yes. The app supports multi-file input and mixed source formats in the same batch.

Can I convert a mixed batch to different output formats in one click?

No. One batch run targets one selected output format. If you want both WEBP and AVIF versions, run the batch twice.

Does the app preserve original EXIF and camera metadata?

You should not assume that it does. The current architecture decodes pixels and re-encodes new images.

Why does PNG ignore the quality slider?

Because the current PNG path is used as lossless output. The slider is only relevant for lossy or quality-exposed formats in this version.

Why is AVIF often slower to encode?

Because higher-efficiency modern codecs usually require more computation. That trade-off is normal.

Why use MozJPEG instead of just saving a normal JPEG from the browser?

Because MozJPEG is specifically designed to improve JPEG compression efficiency while staying compatible with JPEG decoders.

Can I use this tool offline?

If the page and its local codec assets are already available on your device or on your own server, the conversion workflow itself does not require a remote processing backend.

Why is BMP input supported but BMP output is not offered?

Because BMP is mostly useful as a source format in this workflow. For output, PNG, JPG, WEBP, and AVIF are usually more practical.

Conclusion

CasinoLove Image Converter is designed as a practical open-source browser utility rather than a cloud service. It focuses on clear batch workflow, practical output choices, optional proportional resize, compact previews, ZIP export, and self-hosted codec assets. For users, that means a fast and private image conversion tool. For developers, it means a simple architecture built from understandable browser primitives and well-known upstream codec projects.