Custom PRD build: an in-browser JPEG XL converter that shows the byte delta
Reviewed by the OnlineFree.app team · Updated
Key points
- Custom PRD build converts JPEG, PNG, WebP and JPEG XL locally in the browser and never uploads your file.
- The size-compare bars show original bytes, converted bytes and the delta percentage for your specific image.
- Lossless mode defaults on for PNG and JXL input, and off for JPEG and WebP input.
- Encoder effort maps to libjxl levels 3, 5 and 7; max can exceed ten seconds on large photos.
- Input is capped at 25 MB and 40 megapixels, one file at a time, with no batch mode.
Custom PRD build in one sentence
It converts a single image between JPEG, PNG, WebP and JPEG XL entirely inside your browser tab, shows the exact byte difference between original and converted file, and lets you download the result. Nothing is uploaded, so there is no queue, no account, and no server copy of your file.
You drop in a file (or browse for one) that is JPEG, PNG, WebP or .jxl, up to 25 MB and 40 megapixels. The target format defaults to JPEG XL (.jxl) when the input is anything other than .jxl, and defaults back to JPEG when you feed it a .jxl file — the tool assumes you want to go somewhere the input cannot already go. The output keeps your original filename with the new extension and appears behind a Download button.
The value is not the conversion itself — libjxl and several desktop apps do that — but the number next to it. The size-compare panel draws two stacked bars, original in grey and converted in indigo, plus a delta percentage and a verdict line in plain language. A side-by-side canvas preview shows both images at the same zoom so you can judge whether the smaller file still looks like your image.
Who benefits from an in-browser JXL converter?
The primary user is someone with a file on their desktop and a thirty-second question: is JPEG XL actually smaller for my image? That is a web developer auditing a hero image before a re-encode, a photographer deciding whether to archive in .jxl, or a performance engineer reacting to the JXL-in-browsers debate and wanting evidence rather than a blog post's benchmark chart. Installing libjxl, wiring up cjxl flags and remembering the syntax takes longer than the question deserves.
The second group is anyone who cannot upload. Client photos under NDA, unreleased product shots, internal dashboards, medical or legal images — a browser-local encode means the file never leaves the machine. That is a workflow constraint, not a marketing point: if your policy forbids third-party uploads, a client-side converter is the only kind you can use at all.
A third, quieter group uses it in the other direction. When a client sends a .jxl that other software refuses to open, the same page converts it back to JPEG, PNG or WebP without hunting for a viewer. It sits alongside the rest of the free online tools on FreeOnline.fyi as a single-purpose utility rather than a suite.
How to read the size bars honestly
The grey bar is your original file's byte count; the indigo bar is the converted file's. The delta percentage is simply (converted − original) / original, so a file that grew shows a negative saving rather than hiding it. Read the verdict line as a summary of the measurement, not a promise about the format in general.
The most common mistake is comparing a lossy result against an unknown original. If your source is a JPEG saved at quality 75 and you convert at quality 90, the JXL may be larger and still count as an improvement in quality. To compare fairly, either toggle lossless on — the tool defaults it on for PNG and JXL input and off for JPEG and WebP — or convert the original to PNG first so both encoders start from the same untouched pixels.
Always check the preview at identical zoom before trusting the number. Flat skies, gradients and fine text are where lossy encoders show banding or ringing first. If the bars say 40% smaller and the preview shows artifacts in the area that matters, the saving is not free. Re-run at a higher quality setting and watch how much of the delta survives.
Settings that move the byte count
The lossless toggle is the biggest switch. When it is on, the quality slider is ignored and the encoder preserves every pixel; when it is off, the quality slider runs from 1 to 100 with a default of 90 on the JPEG/WebP quality scale. Dropping from 90 to 80 usually shrinks the file noticeably, but you need the preview to tell you whether your particular image tolerates it.
Encoder effort offers fast, balanced and max, which map to libjxl effort levels 3, 5 and 7. Balanced is the default and is fine for most checks. Max can take longer than ten seconds on a large photo — the tool warns you — and the difference it buys is often a few percent, not a few tens of percent. Try balanced first, then max only if you are deciding a final export.
Keep metadata defaults to on and preserves EXIF orientation and the ICC profile where the target format supports them. Turning it off shaves a small number of bytes but can rotate a phone photo the wrong way or shift colours noticeably on a wide-gamut file. If you disable it, check the preview and the downloaded file's orientation before you ship it.
What are the limits of browser-based JXL encoding?
It handles one image at a time, caps input at 25 MB and 40 megapixels, and rejects anything else outright. There is no batch mode, no folder drop and no CLI. For a hundred product images, a desktop build of libjxl is the right tool; use this one to decide what settings to apply at scale.
Browser encoding also competes for memory with every other tab you have open. Very large images on a low-memory device can stall or fail, and the failure is usually a silent slowdown rather than a clean error. Close heavy tabs if a 40-megapixel file refuses to finish.
Finally, treat every number as the measurement it is: one image, one set of settings, one browser build. JPEG XL is standardised as ISO/IEC 18181 and described by the JPEG committee, while PNG's behaviour is fixed by the W3C PNG specification — but neither tells you what your photo will do. Re-verify anything that goes into a budget document, and use Custom PRD build for the quick check rather than the final authority.
Frequently asked questions
Does Custom PRD build upload my images to a server?
No. Custom PRD build converts the file inside your browser tab, so the image never leaves your device and no copy is stored anywhere. That makes it usable for client work, unreleased assets or any file your policy forbids sending to a third party. The download is generated locally from the in-memory result.
Is Custom PRD build free, and do I need an account?
Yes, it is free and requires no sign-up, install or extension. You open the page, drop an image and get the converted file plus a size comparison. There is no usage counter, no watermark on the output and no paid tier that unlocks larger files; the only hard limits are the 25 MB and 40 megapixel caps.
What formats and file sizes does Custom PRD build accept?
It accepts JPEG, PNG, WebP and JPEG XL input up to 25 MB and 40 megapixels, and converts one file at a time. The target format defaults to .jxl for non-JXL input and back to JPEG for .jxl input. Anything over the size or resolution cap is rejected rather than silently truncated.
Is JPEG XL always smaller than JPEG?
No, and Custom PRD build exists precisely so you can check your own file instead of trusting a general claim. A lossy JXL at quality 90 compared against a low-quality source JPEG can be larger. Re-encode from a lossless PNG, or toggle lossless on, to get a comparison that actually means something.
Why does the max encoder effort setting take so long?
Max maps to libjxl effort level 7, the slowest encoder setting, and Custom PRD build warns it may run longer than ten seconds on a large photo. Balanced maps to effort 5 and is usually close in size. Use max only when you are producing a final export and a few percent matters.