Image Resizer

What it does

The Image Resizer takes any image (PNG, JPG, WebP, or others your browser can decode) and produces a copy at exact pixel dimensions. Aspect lock is on by default — change one dimension, the other follows — and can be turned off when you need a specific non-proportional size. The whole process happens in your browser using the canvas API; the file never uploads anywhere, so this is the appropriate tool for unreleased brand assets, contract photos, or anything you would rather not hand to a server.

Common situations

You’re publishing a blog post and the hero image arrived at 4000×3000 from the photographer. WordPress will resize it on upload, but its built-in resize is mediocre and bloats the served file. Pre-resizing to the exact <img> slot dimensions (or 2× for retina) produces sharper output and lighter pages.

You’re building product creative for a marketplace that rejects images larger than 2MP. Your source is a 24MP photograph; uploading directly fails silently or the platform crops aggressively. Resizing locally before upload removes the failure mode entirely.

You’re migrating image assets between two CMS platforms with different recommended sizes. The old platform served 1200px-wide hero images; the new one wants 1600px. Batch-resizing the existing library brings the imagery up to the new spec without a re-shoot.

You’re producing email creative where image weight matters disproportionately. Email clients have aggressive size limits and slow rendering on legacy clients (Outlook, in particular, struggles with anything over 1MB). Resizing photographs to email-appropriate dimensions is the routine pre-flight check.

You’re preparing screenshots for documentation that need to fit a specific column width. Shipping 3000px-wide screenshots into a 600px-column makes the page heavy with no benefit. Resizing once during the screenshot capture pipeline saves bandwidth and makes the documentation feel intentional.

What you need to know

The image is decoded to a canvas at its native resolution, then the canvas is redrawn at the target dimensions using the browser’s built-in image scaling. The browser’s scaler is bilinear or bicubic depending on implementation, which is good enough for most use cases — you will not see the difference between this and Photoshop output for normal web sizes. For extreme downscaling (10× or more), specialist algorithms produce slightly sharper results, but they are not the bottleneck most workflows care about.

For web delivery, the standard is 2× the display size. A 600px-wide image slot wants a 1200px source — sharp on retina displays, not so big that it bloats the page. Going to 3× is overkill on most modern displays and noticeably affects page weight; sticking at 1× looks soft on retina screens. 2× is the practical sweet spot.

Output format defaults to match the input — PNG stays PNG, JPG stays JPG. A new image element is generated and offered for download with a filename that includes the new dimensions, which is the small touch that makes batch work easier (you do not end up with five files all called image.jpg).

The output is always re-encoded. Even at the same dimensions, this strips embedded metadata (EXIF, geotags, camera info, copyright fields), which is occasionally useful for privacy. If you need the metadata preserved, resize with a tool that supports lossless metadata transfer (jpegoptim and similar CLI tools, or ImageMagick with explicit metadata-preserving flags).

There are limits to what browser-based resizing can do well. Very large images (above 30MP) consume a lot of memory in the canvas and may produce out-of-memory errors on devices with limited RAM. Animated images (GIF, animated WebP) cannot resize through this tool — animation requires frame-by-frame processing the canvas API does not handle directly.

For images destined for serving via a modern image-delivery service (Cloudflare Images, Imgix, Cloudinary), pre-resizing is often unnecessary — the service produces the right size on demand from a single high-resolution source. The tool is most useful when you are committing static files to a project rather than feeding a delivery service.

Frequently asked questions

How do I resize an image without losing quality?

Some quality loss on resize is unavoidable when the algorithm has to interpolate between pixels. To minimise it: resize from the highest-resolution source you have, downscale only (never upscale), and avoid multiple resize passes (each pass compounds the loss).

What’s the best image size for web pages?

Match the slot 2× — a 600px-wide image slot wants a 1200px source. Larger wastes bandwidth without visible benefit; smaller looks soft on retina displays.

Can I resize images without uploading them?

Yes — this tool runs entirely in the browser via the canvas API. No upload happens. The same is true of any modern image tool that handles files locally; “no upload” is now table stakes for browser-based image work.

What format should I output?

Match the input format unless you have a reason to convert. PNG-in PNG-out preserves transparency; JPG-in JPG-out avoids accumulating compression artefacts from format conversion. To deliberately convert, use the Image Format Converter instead.

Why does my resized image look soft?

Either the source was too small for the target (upscaling is lossy and produces softness), or the browser’s scaling algorithm produced acceptable but not optimal output. For sharper downscaling at extreme ratios, specialist desktop tools (Photoshop, Affinity, Pixelmator) outperform browser scaling.

Does resizing remove metadata from my image?

Yes — re-encoding through canvas strips EXIF, geotags, copyright fields, and camera metadata. This is sometimes desirable (privacy), sometimes not (preserving attribution). If metadata matters, use a tool that explicitly supports lossless metadata transfer.

Can I resize many images at once?

Not in this tool. Single images, one at a time. For batch work, a CLI tool (ImageMagick, sharp via Node, or a build pipeline plugin) is the right answer.

What’s the maximum image size this can handle?

Browser-dependent. Modern desktops handle 30+ megapixel images comfortably; mobile devices may run out of canvas memory at 15-20MP. If a very large image fails to load, downsize via a desktop tool first and refine in the browser.

Common problems

Problem: The resized image looks blurry compared to the source.

You are upscaling — making the image bigger than its source resolution. There are no extra pixels to invent, so the algorithm interpolates and produces softness. Start from a higher-resolution source, or accept the upscale.

Problem: Output file is much larger than expected.

Re-encoding can produce a larger file in two cases: PNG output of a photograph (PNG is lossless and grows with detail), or quality settings producing minimal compression. For smaller output, follow up with the Image Compressor, or convert to a more compact format.

Problem: Resizing strips important metadata I needed.

Re-encoding through canvas does not preserve EXIF, copyright, or other metadata. If you need it preserved, use ImageMagick (convert source.jpg -resize 800 -strip target.jpg for explicit strip, or omit the flag to preserve), or sharp in a Node script with withMetadata().

Problem: The image fails to load — file too large.

Mobile browsers in particular have memory limits on canvas dimensions. Files above ~30MP can fail. Pre-resize via a desktop tool first, then refine.

Problem: Animated GIF resized to a single frame.

Canvas-based resize handles only one frame; animated formats require frame-by-frame processing this tool does not support. Use a dedicated GIF tool (FFmpeg with the right filters, or a desktop GIF editor).

Quick guides

For web image optimisation: Resize to 2× the display size, then run through the Image Compressor at quality 75–85. Output served via <img srcset> for responsive delivery if your CMS supports it.

For email creative: Resize to a maximum width matching the email template (usually 600–800px). Compress aggressively (quality 70). Test rendering in the actual email clients you target — Outlook desktop especially.

For native mobile app assets: Generate at 1×, 2×, and 3× from the same source (e.g. 100px, 200px, 300px versions of a 100-point UIImage). iOS and Android both consume scale-multiplier asset bundles; producing all three at once during asset prep is faster than re-resizing each time.

Tips

• For web delivery, downscale to roughly 2× the display size. A 600px-wide image slot wants a 1200px source — sharp on retina displays, not so big that it bloats the page.
• Aspect-locking on is right for almost every case. Turning it off produces stretched results that read as broken to most viewers — only useful when you genuinely need a non-proportional crop.
• Resize before compressing. A compressed-then-resized image accumulates the artefacts of both operations; resized-then-compressed produces cleaner output.
• The output file is always re-encoded — even at the same dimensions, this strips embedded metadata (EXIF, geotags, camera info), which is occasionally useful for privacy.
• For batch work, a CLI tool (sharp via Node, ImageMagick) handles dozens of files in seconds. Use this tool for one-off cases.
• Pre-resizing is most useful for static asset commits. If you serve images via Cloudflare, Imgix, or similar, the delivery service handles sizing on demand.

Related tools in this suite

The natural pairing is the Image Compressor — resize first, compress second, smaller file size with better quality than the inverse order produces. The Aspect Ratio Calculator is the right starting point if you need to figure out target dimensions for a specific platform before resizing.

What this looks like at scale

Doing this once per asset is fine. Doing it dozens of times a week — for blog posts, social posts, or product uploads — is the kind of repetitive work that should not be human work. The WP Beacon Plugin handles WordPress image optimisation automatically, generating responsive sizes on upload and stripping unnecessary metadata; the systems we build absorb the equivalent work for non-WordPress sites and bespoke product platforms.

Take it further

If image optimisation is a bottleneck — content editors uploading multi-MB photos that bloat pages, or campaigns producing assets that drift from spec — the right answer is build-time automation, not better manual tools. Talk to us about scoping image-pipeline work that removes the question from your team’s daily workflow.