The decision at the start
When JNRT Pixel came into being, there were two possible ways to build it. Variant A, the industry standard: users upload images, a server compresses them, the result comes back. Variant B: all processing happens in the user's browser, and there simply is no server that could receive images. We chose B — not for marketing reasons, but from one simple thought: what we never receive, we can never lose. No database of strangers' holiday photos, no ID copies in an upload folder, no leak risk, no deletion-deadline debates. The privacy policy for the image processing fits into one sentence.
How it works technically
The foundation is less spectacular than many suspect: the Canvas API, which has been in every browser for years. The flow when compressing a JPG looks like this:
- You drag an image into the drop zone. The browser reads the file — from your hard drive into your computer's memory, not over the network.
- The image is drawn onto an invisible canvas element, if needed straight at the target size (that's what resizing does).
- The method
canvas.toBlob()re-encodes the canvas content — as JPG, PNG, or WebP, at the quality level you set on the slider. - The result is offered to you as a download. With multiple images, a JavaScript ZIP library packs everything into an archive — that too locally.
You can verify this in your browser's developer tools, by the way: open the network tab, process an image — no upload request appears. That verifiability matters more to us than any privacy promise in prose.
What the decision gives us
- No limits. Server services cap file size and count because every job costs them compute. With us, your computer does the math — 50 images in a batch cost us the same as one: nothing.
- Speed. The upload disappears entirely. For a 4 MB photo over an average connection, the transfer is often slower than the actual compression.
- It works offline. Once loaded, the tools keep working on a plane.
What it costs us — the honest side
Workshop notes means: the downsides belong on the table too.
- We can only do what your browser can do. The Canvas API encodes JPG, PNG, and WebP — but no AVIF (encoding is barely supported so far) and no HEIC. A server with its own codecs could; we deliberately don't. Why we still don't add a HEIC button that secretly uploads after all is covered in its own workshop report.
- Your device's memory is the limit. A 100-megapixel panorama unpacks to several hundred megabytes in memory — on an older smartphone that can overwhelm the tab. A server service with beefy hardware would have more headroom here.
- Color management stays at basic level. Browsers mostly compute internally in sRGB. For web images that's exactly right; anyone preparing Adobe RGB photos for print still needs a desktop program with ICC profile management.
For the tasks our tools are built for — preparing images for the web, for job applications, for messengers and portals — none of these limits plays a practical role. But it would be dishonest to keep quiet about them.
A side effect we hadn't planned
The architecture decision shaped our offering: because there's no server, there are also no accounts, no "3 images per day free" barrier, and no premium plan that lifts the limits. The site is funded by advertising — we lay that out openly on our about page — and the tools remain fully usable, with or without ad consent.
Try it yourself
The fastest way to form your own judgment: send an image through compression, resizing, or the converter — with the network tab open, if you don't want to take our word for it. That's exactly what we'd do in your place.