Image Resizer & Compressor

Why people resize and compress images

The gap between a phone photo and a picture on a website is obvious at a glance. A shot from a modern camera weighs several megabytes, is three or four thousand pixels wide and suits printing, but fits an article, a news feed or a dashboard very poorly. A page wants an image around 1200 pixels across and a few hundred kilobytes, not several megabytes. That difference in weight turns directly into load time and into data charges for every single visitor.

The second scenario, which comes up everywhere, is preparing pictures to send. A photo attached to a support request, a screenshot in a ticket, a picture in a CV, a file in a messenger. None of these systems need the original resolution, and the weight limits are usually strict. Compressing the file on your own machine is quicker and safer than working out an upload service's requirements, especially when personal data is involved, since that is data you would rather not send through somebody else's server at all.

The third scenario is getting a site ready to publish. Images in a gallery, thumbnails, banners and favicons, diagrams and screenshots inside articles, avatars in comments. All of it is easier to prepare with one tool and an honest savings counter. Worth knowing: when a picture is re-encoded through canvas, the EXIF service data, geolocation and camera model do not carry over to the new file. For cutting a region out rather than shrinking the whole picture, the image cropper is the tool to use.

• Preparing pictures for an article, a blog post or a news feed.
• Compressing a photo before sending it to support, to a job application or over a messenger.
• Bringing avatars and icons to the size a service asks for.
• Optimising galleries and thumbnails on a page before it goes live.
• Shrinking screenshots that go into a bug report or a task.
• Preparing images for a newsletter that has an attachment size limit.
• Reducing the weight of diagrams without making them unreadable.
• Converting photographs to WebP for a site that supports it.

Mistakes that leave you with a worse file

The first mistake is visible immediately: shrinking a picture below what you need and then scaling it back up. Resolution does not appear out of nowhere, the picture simply becomes softer and blurrier. If the source is small, leave it small instead of trying to make it big. The second mistake runs the other way, choosing PNG for a photograph. PNG compresses losslessly and keeps transparency, but a photograph barely compresses inside it, so the file ends up larger than the original.

The third mistake is about transparency. If an image has transparent areas and you pick JPEG for the output, the transparency is gone and is usually replaced by a black background. PNG and WebP keep it, JPEG simply cannot hold it. The fourth mistake concerns animation: an animated GIF or APNG is drawn onto the canvas as a single frame, so the animation disappears without any warning.

The fifth mistake is worth knowing on its own, and it is about quality. The quality slider only applies to JPEG and WebP, since PNG has no such parameter. Too low a value produces visible artefacts around contrasty details, while too high a value costs file weight without a visible difference. A practical rule: 75 to 85 percent is enough for publishing on the web, and start at 85 for photographs with fine detail. The savings counter on the page reports the result honestly, including the cases where the file grew.

• Stretching a small source up to a large size. No extra resolution appears.
• Picking PNG for a photograph. The result ends up bigger than the original.
• Moving from a transparent PNG to JPEG. Transparent areas turn into a black background.
• Expecting an animated GIF to stay animated. Only the first frame survives.
• Ignoring the quality slider, which is where most of the weight saving comes from.
• Setting the quality too high. The file gets heavier for almost no visible difference.
• Assuming EXIF survives processing. Re-encoding through canvas drops it.
• Uploading the result to a service that only accepts one specific size, without checking the dimensions.

How resizing and compression work

The work runs in three steps. First the browser decodes the file and learns its natural size, then the new dimensions are calculated from the chosen mode: with a target width the height follows from the proportions, with a target height the width follows, and in percentage mode both numbers are scaled by the fraction. Next a canvas of the new size is created with high-quality smoothing, and the source picture is drawn onto it.

The last step, encoding, is handed to the browser's own encoder. The function `canvas.toBlob` takes a file type and, for JPEG and WebP, a quality value from 0.1 to 1. The slider here runs from 10 to 100 percent and is clamped into that range, with 80 as the default. PNG accepts no quality parameter at all, so none is passed for it. The size of the result is measured in bytes and compared with the original, which is where the savings percentage comes from.

It helps to know what the tool does not do. It does not add detail, it redraws the picture at a new size, so when shrinking, some pixels are averaged, and that is normal. It keeps no metadata, no EXIF, no embedded profiles. And it does not replace server-side compression: if your site serves images through nginx with gzip or through a CDN with automatic optimisation, browser-side preparation still pays off, because it hands the server a lighter file to begin with.

Proportions are always preserved. When you give only a width or only a height, the other number is calculated automatically.

Different ways to make a picture smaller

There are three routes to a smaller image, and they produce different results. Simple resizing in a graphics editor redraws the picture and gives roughly what browser canvas does. Server-side optimisers such as ImageMagick or Nginx modules are more careful, because they use quality filters like Lanczos and usually look better at the same speed. Purpose-built CDN services can change format and size straight from the URL, which suits sites with a lot of images.

Compression during transfer is worth mentioning too. WebP and AVIF already contain their own compression, while JPEG, still the most common format, is often gzipped on the server as well. PNG is already compressed, so gzip buys it almost nothing while costing processing time. The practical conclusion is simple: bring the picture to sensible dimensions and a sensible format on your own machine first, then hand it to the server as it is.

Sometimes no compression is needed at all. If the picture is already small and the task is to look at it or compare two versions, it is wiser to leave the file alone. For viewing there is the image viewer, for comparing metadata the text comparison tool, and for embedding a picture directly in code the Base64 image encoder. And if the job is to cut out a region rather than shrink the whole picture, that belongs to the image cropper.

To size up a project, the word and character counter handles text and the image resizer gives an honest figure for pictures.

Habits that save time and quality

Image optimisation becomes predictable once you understand what actually drives file weight. Pixel dimensions and compression quality decide almost everything, and the rest is secondary.

• Decide where the picture will be shown before you pick a size.
• Shrink rather than enlarge. Extra pixels in a stretched image only add weight.
• Start at 80 percent quality and go higher only if the picture genuinely looks mushy.
• Remember PNG is wrong for photographs and JPEG is wrong for transparent images.
• Watch the savings counter. It shows the case where the file grew as well.
• Do not expect EXIF or geolocation to survive. They will be stripped.
• Check animation. If a GIF has to stay animated, do not push it through canvas.