DEV Community

Cover image for I Built an Image Compressor Because “Just Upload the Image” Wasn’t Good Enough
axevora
axevora

Posted on

I Built an Image Compressor Because “Just Upload the Image” Wasn’t Good Enough

Have you ever tried to upload an image to a website and suddenly got hit with:

“File size too large.”

So you open an image editor.

Export it again.

Change the quality.

Save another copy.

Check the file size.

Still too large.

Repeat.

And after doing all that, you sometimes end up with an image that is significantly smaller… but also looks noticeably worse.

That small problem is what made me build an image compressor inside Axevora.

Not because image compression is a new problem.

It obviously isn't.

There are hundreds of image compression tools already available.

The interesting part is making the process simple enough that you don't have to think about it.

Why image compression actually matters

Images are one of those things that can quietly make a website heavier.

A camera photo, screenshot, design asset, product image, or even a simple blog image can easily be several megabytes.

Now imagine a page loading ten or twenty of those images.

The browser has to download them.

The server has to deliver them.

The user's connection has to transfer them.

And the page has to process everything before the visitor gets the experience you intended.

That means image optimization isn't just about saving disk space.

It can also be about:

  • Reducing the amount of data transferred
  • Making pages load faster
  • Reducing bandwidth usage
  • Making images easier to upload
  • Keeping websites lighter
  • Making media workflows less annoying

The funny thing is that most people don't actually want to become image-compression experts.

They just want the file to be smaller.

Without destroying it.

The problem with traditional image compression workflows

The usual workflow looks something like this:

  1. Open an image editor.
  2. Import the image.
  3. Find the export settings.
  4. Change quality.
  5. Export.
  6. Check the file size.
  7. Open the new file.
  8. Decide whether the quality is acceptable.
  9. Go back and repeat.

For someone who works with images every day, that's manageable.

For everyone else?

It's unnecessary friction.

I wanted the workflow to be closer to:

Drop → Adjust → Compare → Download.

That's it.

So I built an Image Compressor

I added an Image Compressor to Axevora:

https://axevora.com/tools/image-compressor

The goal was simple:

Make image compression feel like a normal browser task instead of a mini editing project.

You can drag and drop your images into the compression area, adjust the quality, compare the original and compressed versions, and download the optimized files.

The tool currently supports:

  • JPG
  • PNG
  • WebP

It also supports processing multiple images, with a “Download All” option for the optimized files.

The quality slider is the important part

One thing I didn't want was a mysterious “Compress” button where the user has no idea what is happening.

Image compression is always a trade-off.

Smaller file size usually means some form of quality reduction.

The question is:

How much quality are you willing to trade for how much size reduction?

That's why the tool includes a quality slider from 0 to 100.

Move it toward smaller files.

Move it toward higher visual quality.

Then compare the result.

For normal web images, a reasonable quality setting can often produce a much smaller file without an obvious difference at normal viewing sizes.

The important thing is that you can actually see the result before downloading it.

Original vs Compressed

This is probably my favorite part of the workflow.

Instead of compressing an image and blindly trusting the result, you can compare:

Original

vs.

Compressed

side by side.

That matters because file size is only half of the equation.

A 90% reduction sounds amazing until you realize that the image now looks terrible.

The real objective should be:

Reduce unnecessary bytes while keeping the image visually useful.

That's a much better target.

Why JPG, PNG and WebP?

Different image formats exist for different reasons.

JPG

JPG is still extremely common for photographs, screenshots, blog images, thumbnails and general-purpose web images.

It can provide significant size reductions for photographic content.

PNG

PNG is useful when you need lossless compression or images with transparency and sharper graphical elements.

Logos, interface graphics and certain illustrations are common examples.

WebP

WebP was designed with the web in mind and can provide efficient image compression while supporting modern web use cases.

The important thing is that you shouldn't have to install three different applications just because you have three different image formats.

That's why I wanted all three available from the same place.

Where image compression becomes really useful

This isn't only for developers.

There are a lot of everyday situations where image compression saves time.

1. Website owners

If you're uploading images to a website, smaller files can mean less data being transferred to visitors.

2. Bloggers

Large hero images and article images can quickly increase the amount of data your pages need to load.

Compressing them before uploading is a simple optimization step.

3. Developers

If you're building a web application, you eventually end up dealing with image uploads.

User avatars.

Product images.

Screenshots.

Attachments.

Profile pictures.

Content management systems.

Having smaller assets can make the whole pipeline easier to manage.

4. E-commerce

Product photography can generate huge files.

If you have hundreds or thousands of product images, unnecessary image size can become a real operational problem.

5. Social media creators

Creators constantly move images between phones, computers, websites and publishing platforms.

Sometimes the platform simply doesn't need a 5 MB image.

A smaller optimized version is enough.

6. Students and professionals

Sometimes you just need to upload an image to a form, application, document system or portal that has a file-size restriction.

Instead of opening a full image editor, you can compress the file and move on.

One thing I learned while building this

Image compression sounds simple until you start thinking about the actual user experience.

The compression algorithm is only one part of the problem.

You also need to think about:

  • What happens when multiple files are selected?
  • How does the user know compression is happening?
  • How do they compare the result?
  • What happens when an image is already small?
  • How should quality be controlled?
  • How should the resulting files be named?
  • How can multiple optimized files be downloaded?
  • What happens when the user wants to try another quality setting?

A technically working compressor isn't necessarily a good compressor from the user's perspective.

The workflow matters just as much.

The goal: fewer clicks

This is something I keep coming back to while building Axevora.

If a tool solves a small problem, the interface should respect the user's time.

You shouldn't need a tutorial to understand an image compressor.

You shouldn't need to create an account just to test whether an image can be reduced.

You shouldn't have to navigate through five screens to get the final file.

The ideal workflow is almost boring.

And that's a good thing.

Upload the image.

Adjust the quality.

Look at the result.

Download it.

Done.

What I'd like to improve next

The current version solves the basic compression workflow, but there are still plenty of directions this can go.

Some ideas I'm considering:

  • Better compression presets
  • More detailed size comparison
  • Before/after percentage reduction
  • More control over output formats
  • Better handling of very large images
  • More advanced batch workflows
  • Additional image optimization options

The challenge is adding useful features without turning a simple tool into a complicated dashboard.

That's the balance I'm trying to maintain.

If you work with images, give it a try

If you've ever had to reduce an image from several megabytes to something that a website will actually accept, you already know why this kind of tool is useful.

I built the Axevora Image Compressor to make that process quicker and less frustrating.

Try it here:

👉 https://axevora.com/tools/image-compressor

Drop in an image.

Move the quality slider.

Compare the original with the compressed version.

Download the result.

And if you're working with multiple images, you can process them together and download the optimized files.

No complicated image editor.

No unnecessary workflow.

Just compress the images and get back to what you were doing.


One last question for developers 👇

When you build web applications that accept image uploads, what's your preferred approach?

Do you:

  • Compress images in the browser?
  • Compress them on the server?
  • Use an external image-processing service?
  • Let users upload anything and optimize later?

I'm especially interested in how people are handling this in production applications.

Let's compare approaches in the comments.

Axevora
🚀 Compress your images now — reduce file size, compare the result, and download your optimized images.

Top comments (0)