Bulk Image DPI Changer
Drop a batch of JPG or PNG files and set every one to 300 DPI — or any value. Built for print shops, POD/Etsy sellers, photographers delivering to labs, and archive scans. Density tags are rewritten losslessly in your browser. Download the whole set as one zip. Nothing is uploaded.
Who needs to change DPI in bulk
Print shops see this every week: a client hands over a folder of 60 JPEGs, every one tagged 72 DPI because that is what the camera, the phone, or “Save for Web” wrote. Preflight rejects the job as low resolution even when the pixel counts are fine. Opening each file in Photoshop to untick Resample and type 300 is not a workflow. The shop needs the whole folder rewritten, same pixels, new density tag, and a zip to send back or to drop on the RIP.
POD and Etsy sellers have the same shape of problem with a different label. A printable shop listing 30 wall-art files cannot upload half of them at 96 DPI and hope buyers’ printers ignore the tag — they will not. Photographers delivering a wedding or portrait gallery to a lab get one rejection email for the set when Lightroom exported 72. Archive and scan projects are worse on volume: a box of correspondence scanned as PNG or JPEG may be hundreds of pages, all of which should carry the scan DPI in pHYs or JFIF so a later reprint or OCR pipeline knows the intended inches.
The bulk image DPI changer is built for those four desks. It is not a different engine from the homepage Image DPI Changer — same JFIF/EXIF/pHYs rewrite, same lossless promise — it is the same engine with a drop zone that expects a batch and a button that packs every converted file into one zip. If you only have one picture, the homepage is enough. If you have a folder, stay here.
What happens to each file (and what doesn't)
For every file in the batch the tool does the same metadata-only rewrite. Pixels are never re-encoded. The picture on disk stays the same size, give or take a few dozen bytes if a missing density chunk had to be inserted.
| Format | What is written | What is not touched |
|---|---|---|
| JPEG | JFIF density; EXIF XResolution, YResolution, ResolutionUnit when an EXIF block is present | Scan data (SOS payload) — never decoded, never recompressed |
| PNG | pHYs chunk (pixels-per-metre, unit = 1) | IDAT pixel bytes; other chunks stay put |
On JPEG, units are set to inches and Xdensity = Ydensity = your target. If a JFIF APP0 or an EXIF APP1 segment is missing, a small one is inserted after SOI. Existing EXIF other than those three IFD0 tags is left alone. On PNG, pHYs is updated in place when it already exists; otherwise it is inserted before the first IDAT, and the chunk CRC is recalculated. IDAT is copied as-is.
What does not happen: no decode, no resample, no second JPEG encode, no upload. Pixel width and height stay the same. A 4.2 MB camera JPEG is still a 4.2 MB camera JPEG after you set 300 DPI on it, and doing this to 200 files does not degrade the set. Tools that “convert DPI” by opening the picture and saving it again quietly pay a generation of compression on every file in the folder. There is no reason to.
Batch limits and memory
This page does not stream to disk and it does not talk to a server. Originals, converted copies, and the zip all live in the tab’s RAM. That is the cost of “nothing is uploaded,” and it is the limit you have to plan around.
Each drop or file-picker selection keeps its first 200 files; you can drop again, so a batch can grow past 200. Everything stays in RAM, so a few hundred megabytes is a sensible ceiling on a laptop — advice, not a hard limit. The page refuses to build a zip if the converted files add up to more than 800 MB and asks you to split the batch. The archive is built with the ZIP STORE method (no compression) from the already-converted Uint8Arrays, so the zip is roughly as large as the converted files themselves.
Refresh the page between batches. That drops the previous arrays. Closing the tab does the same. There is no server-side queue and no resume — if the tab dies, start the batch again. The file input already accepts multiple files; you can also drop a selection from a folder. Only JPG and PNG are read. Other types get an alert and are skipped.
File naming
Each converted file is named with the same rule as the homepage tool’s outName: the original stem, an underscore, the target DPI, the letters dpi, then the original extension. photo.jpg becomes photo_300dpi.jpg. scan.PNG becomes scan_300dpi.PNG. A file that was already called invite_300dpi.jpg becomes invite_300dpi_300dpi.jpg — the tool does not try to be clever about prior suffixes.
The zip itself is named setdpi-300dpi-batch.zip, or whatever DPI you chose. Names inside the zip are stored as UTF-8 (ZIP flag 0x0800), so non-English filenames survive. Compression method is STORE — no deflate — so the zip is a container, not a second encoder. That keeps the promise that pixel bytes are not recompressed on the way into the archive.
Bulk DPI is not bulk resizing
Setting 300 DPI on 50 files does not turn 50 small pictures into 50 large prints. Print inches = pixels ÷ DPI. A 600 × 600 px icon tagged 300 still prints 2 × 2 inches. Raising the tag does not add pixels. It only changes the inches a printer or a preflight tool will claim those pixels occupy.
If a lab rejected the folder for “low resolution,” check two things: the tag (this page) and the pixel count (not this page). Use the DPI Calculator to see the print size you actually have. If you need more pixels, that is resampling or an upscaler — see Increase Image DPI for what raising a tag can and cannot do.
This bulk changer will happily write 300 on a 400-pixel-wide image. Preflight that also checks pixel dimensions will still bounce it. Read the rejection; fix the tag here only when the tag was the problem. Same pixels, new label, one zip. That is the whole job.