seokopat · product
> product.open("compresify")
Compresify
Compresify brings images down to just under the point where the difference stops being visible. The work happens in the user's own browser rather than on a server. The real job of the product is not running codecs, it is deciding which codec at which setting for each individual image.
Images turned out to be the line item we ran into most often in site speed work. Most of a page's weight is usually carried by pictures, and fixing that is both faster and cheaper than fixing everything else. But once the conversation reached the client, the same question came back every time: with which tool, done by whom, and how.
Most online tools take the same route. They upload your file to their servers, process it there and hand the result back down. That creates two problems. First, waiting: upload and download take longer than the work itself. Second and more seriously, your file sits on a computer you do not know. When it is a scan of an ID or a screenshot of a contract, that stops being a matter of convenience.
Compresify removes that step entirely. The compression code is downloaded to the browser once and the work runs on the user's own processor. The file never touches the network. That choice has a price, and we have written it down below.
The problem it solves
One fixed quality value does not suit every image
Most tools apply the same setting to a landscape photograph and a flat colour logo alike. The result is either a needlessly large file or visible degradation. Both push the user into manual trial and error.
Personal images end up on someone else's server
To process an image containing an ID, a report, a contract or a customer photo, you have to upload it to a service you know nothing about. Every transferred piece of data becomes data you have to protect and account for.
Forms with a KB limit force guesswork
When an application system sets a hard limit, you end up dragging a quality slider and exporting over and over. Instead of stating the target and getting the result, hitting the target becomes the user's job.
Batch work is missing from most tools
With hundreds of product photographs, uploading and downloading one at a time is not realistic. Tools carrying server costs also have to cap file counts and sizes.
What sets it apart
The work is local, the file stays put
Codecs run in the browser through WebAssembly. With no upload or download step there is no waiting, and no copy of the file is left anywhere. The claim is verifiable: open the network tab in developer tools and you will not find a request carrying your file.
The engine makes the call
Each image is analysed first: photographic or a low colour graphic, transparency or not, what resolution. Format follows from that analysis and the quality value is calculated per image. No fixed number is applied.
Quality scales are aligned
Every format has its own quality scale, and a given value in one does not mean the same in another. The engine aligns those scales internally, so changing format does not hand the user a different sense of quality.
Target size mode
Rather than moving a quality slider you state the file size you need to reach. The engine searches the quality range and finds the best result that stays under that limit. The system hits the limit, not the user.
What is inside
The product is in development. This list shows scope; order and detail can shift with the roadmap.
Compression engine
- automatic format selection based on content analysis
- quality value calculated per image
- target file size mode
- quality scale alignment across formats
Format support
- AVIF and WebP as the defaults for the modern web
- JPEG and PNG wherever compatibility is required
- JPEG XL in scope for archival work
- a lossless path for images with transparency
Batch work
- dropping multiple files and whole folders
- downloading the result as a single ZIP
- before and after sizes shown side by side
- manual format and quality override when you dislike the result
Privacy
- files never reach the network, the work stays on the device
- EXIF fields such as location and device model stripped
- an option to keep them, the decision stays with the user
- no account or sign up required to use it
How it works
- 01
The image is dropped in
The file is read into browser memory and does not go online. One file or a full folder both work; the practical limit is the memory of the device.
- 02
The engine analyses it
Photographic or graphic content, transparency or not, what resolution. That analysis becomes the input for the format and quality decision.
- 03
Quality is searched against the target
The engine searches the quality range: it compresses, compares the output with the original and measures whether the difference stays below the point of visibility. The goal is the smallest file where the difference still cannot be seen.
- 04
Compare and download
Before and after are shown side by side. If the result is not good enough, format and quality can be set by hand in the advanced options. Nothing that is not downloaded is stored.
Who it fits
Good fit
- teams fighting image weight in site speed and Core Web Vitals work
- e-commerce operations that have to prepare hundreds of product photographs at once
- organisations that do not want to upload images containing personal data
- users stuck on the KB limits of application and government portals
- publishers who want image weight under control while producing content
Not a fit
- anyone looking for an automated processing pipeline on the server side
- setups that have to support very old devices and browsers
- video compression needs, since the scope here is images
- work that has to go live today, since the product is still in development
Technical foundation
The compression codecs run in the browser through WebAssembly, which is possible because codecs once limited to desktop tools now run on the web. The cost of that architecture is real: the codecs have to be downloaded on first use and the speed of the job depends on the user's processor. We accepted it, because in return the file never reaches the network. Page copy and FAQ sections are served as static HTML, while the codecs load only once the user drops a file in.
Where the product stands
Compresify is still in development. If image weight is holding your site back today, write to us anyway: we can look at your current images, advise on format and sizing, and let you know when the product opens. We are not naming a date, because we do not want to promise something we cannot keep.
Frequently asked
Is Compresify live?
No, it is in development. This page explains what the product is and the architectural decision it is built on. Once it launches we will link from here to compresify.com.
Why the browser rather than a server?
Processing on a server would have been easier, but then the user's file sits on our machine. With images holding personal data that creates a bigger responsibility than the one we set out to solve. Data that is never transferred does not become data you have to protect.
What did that choice cost you?
Two things. The codecs have to come down to the device on first use, and processing time depends on the user's hardware, so a phone lags behind a desktop on very large files. In exchange, upload and download waiting disappears completely.
How much smaller does it get?
It depends on the image, and we do not quote numbers we have not measured. The efficiency of the source format, the density of detail in the content and the chosen mode all decide the outcome. An already compressed image naturally has less to give. Rather than guessing beforehand, Compresify computes the result and shows the real figure.
What about images containing personal data?
Since the file never leaves the device there is no transfer to account for. EXIF fields such as location and device model are also stripped by default, which saves a few KB and stops you revealing where a photograph was taken when you share it. You can turn the stripping off if you want it kept.
Can we wire it into our own workflow?
The product itself is a tool that runs in the browser. If what you need is an automated image pipeline on the server side, that is separate work and belongs in a software development conversation. Keeping the two apart is the more honest answer.
If image weight is slowing your site down
How many images do you work with, what formats are they in and where exactly are you losing page speed. We can help with this before the product is ready.
Related work
Compresify makes the most sense inside these services.