Image Resizer

Resize an image by changing its actual pixel dimensions

Image Resizer changes the raster grid itself. A 2400 × 1600 image resized to 1200 × 800 contains a new 1200 × 800 pixel result; this is different from merely displaying the original image smaller with CSS or changing print-resolution metadata.

SnakTool accepts one validated JPEG, PNG or WebP and keeps that source format while drawing the decoded image into a canvas at the requested output dimensions. Use resizing when a website, form, avatar, email workflow or application requires a particular pixel width or height.

Changing pixel dimensions can also affect file size because the output contains a different number of pixels and is re-encoded. It does not, however, guarantee a particular number of kilobytes. Compression, format and image complexity remain separate factors.

Use one dimension when the other should be calculated automatically

In pixel-dimensions mode with aspect ratio locked, you can enter a width and leave height at 0. SnakTool calculates the proportional height from the source ratio. The same works in reverse when you enter a height and leave width at 0.

For example, a 1200 × 800 source resized to width 600 with height left automatic becomes 600 × 400. This is often the simplest way to satisfy a maximum web width without doing aspect-ratio arithmetic yourself.

If both width and height are left at 0, there is no requested output size and the tool rejects the job. With the aspect ratio unlocked, both dimensions must be supplied because there is no proportional rule from which to calculate the missing side.

With aspect ratio locked, two dimensions define a fit-within box

When you enter both width and height while keeping the ratio locked, SnakTool treats them as maximum bounds. It chooses the smaller of the width scale and height scale so the whole image fits inside the requested box without stretching or cropping.

A 1200 × 800 source fitted into 600 × 600 therefore becomes 600 × 400. The remaining 200 pixels of potential box height are not filled with padding, and the image is not stretched vertically to become square.

This behavior is useful for constraints such as 'no wider or taller than 600 pixels.' If the destination requires an exact square composition such as 600 × 600 with no empty conceptual space, crop to the desired aspect ratio rather than forcing a rectangular photo into a square.

Input

1200 × 800 source; width 600, height 600

Method

Use the smaller scale: min(600/1200, 600/800) = 0.5

Result

600 × 400 with aspect ratio locked

Unlock the aspect ratio only when distortion is intentional

With aspect-ratio locking disabled, the width and height become independent exact dimensions. A 1200 × 800 image requested at 600 × 600 is resampled directly to 600 × 600, changing the shape of subjects in the picture.

This can be appropriate for technical assets where independent scaling is genuinely required, but it usually looks wrong for photographs, logos and illustrations. Circles become ovals, faces become wider or narrower, and typography changes proportions.

If you need exact dimensions while preserving natural proportions, crop and resize are usually the relevant pair of operations: crop changes which part of the scene remains, while resize changes how many pixels represent that remaining composition.

Percentage scaling is useful when the relationship matters more than a target width

Percentage mode scales both source dimensions by the same factor, so the image shape is preserved automatically. SnakTool accepts percentages from 1% through 400% and rounds each calculated dimension to the nearest whole pixel, with a minimum output dimension of one pixel.

At 50%, a 1200 × 800 image becomes 600 × 400. At 200%, it becomes 2400 × 1600, provided the resulting image remains inside the tool's resource limits.

Percentage scaling is convenient for 'half size' or 'double size' tasks. Pixel mode is usually clearer when a destination gives an explicit requirement such as 1080 pixels wide, 512 × 512, or a maximum width and height.

Downscaling removes pixels, so inspect small text and fine structure

Reducing dimensions is resampling: many source pixels have to be represented by fewer output pixels. This is why a smaller image can lose fine texture and why tiny lettering, thin lines and high-contrast interface elements deserve inspection after a large reduction.

The browser canvas performs the scaling when SnakTool draws the source bitmap at the new dimensions. Browser image scaling normally uses smoothing when raster images are resized, but the tool does not expose a selectable resampling algorithm or a sharpness control.

A thumbnail does not need the same detail as a full-screen image, so some loss from downscaling is expected and often useful. Judge the result at the actual display size instead of zooming a small output far beyond the size it was created for.

Upscaling creates more pixels but cannot recover missing detail

Increasing width or height makes a larger pixel grid by interpolating the pixels already present. It does not reveal detail that the camera, scan or previous resize never captured. Scaled-up raster images can become blurry because the new pixels have to be estimated from existing ones.

SnakTool allows percentage values above 100% up to 400%, and pixel-dimension mode can also request a larger result within the configured limits. That capability should not be confused with AI super-resolution, sharpening or detail reconstruction; none of those operations are part of this resizer.

Upscaling can still be useful when software requires a minimum pixel dimension or when a modest enlargement is acceptable. Inspect faces, text, logos and hard edges closely before using a significantly enlarged result.

The image format stays the same, but the file is re-encoded

Resizing a JPEG produces JPEG, PNG produces PNG, and WebP produces WebP. The tool is not silently choosing a different format to chase a smaller file. Use a dedicated converter when format compatibility or a different encoding format is the actual goal.

The resized image is nevertheless a newly encoded file, not a byte-preserving edit of the original container. For this resize operation the current engine uses its default browser encoding quality path rather than exposing the Image Compressor quality slider.

This is another reason file size is not predictable from dimensions alone. Fewer pixels often reduce the amount of image data, but re-encoding characteristics and image content influence the final bytes.

Transparency can survive in formats that support alpha

The resize path keeps the source format and creates a transparent-capable canvas for non-JPEG output. PNG and WebP can therefore preserve transparent pixels through supported browser encoding, while JPEG remains an opaque format.

Resizing semi-transparent edges still resamples their pixel values, so inspect logos, icons and cut-out subjects after a large size change. Alpha support means transparency can be represented; it does not mean a heavily resampled edge is mathematically identical to the source.

If the final destination specifically requires JPEG, that is a format-conversion decision because JPEG cannot store alpha. Use the PNG-to-JPG or WebP-to-JPG workflow where the background color can be chosen explicitly.

Pixel dimensions, file size and print resolution answer different questions

A width of 1200 pixels describes the raster grid. Kilobytes or megabytes describe encoded file size. PPI or DPI is commonly used when relating pixels to physical print size. These values influence different parts of an image workflow and should not be treated as interchangeable limits.

SnakTool's Image Resizer works with pixel dimensions and percentage scaling; it does not offer a field for changing print-resolution metadata while keeping the same pixel grid. Resampling is the operation that actually adds or removes pixels.

For a website requirement such as 1200 pixels wide, use the pixel dimension directly. For a maximum upload size such as 500 KB, resizing may help but you still need to check the resulting bytes. For a print specification, confirm the required pixel dimensions and print workflow rather than assuming a pixel resize alone sets the intended physical size.

Browser-local resizing has limits based on decoded pixels, not only file bytes

SnakTool decodes and resizes the selected image locally in a browser worker with an offscreen canvas instead of sending it to a SnakTool image-processing backend. The source contents are validated as JPEG, PNG or WebP before the resize path runs.

The normal image policy allows up to 8192 pixels on either side, 32 million pixels and 192 MiB of estimated memory, with a 25 MiB maximum output and 60-second processing ceiling. Known low-memory devices use tighter limits including 4096 pixels per side and 12 million pixels.

The engine checks both source and requested output resources. This matters for upscaling: a small compressed source can request a much larger decoded canvas, and memory cost grows with pixel count even if the original file itself occupies relatively few megabytes.

Choose resize, crop or compression according to what must change

Resize changes the number of pixels across the whole image. Crop removes part of the visible composition. Compression changes how image data is encoded to reduce bytes while normally keeping dimensions. Treating these as separate operations makes requirements easier to satisfy.

If a 4000 × 3000 photo only needs to display at 1000 pixels wide, resizing addresses the unnecessary pixel dimensions directly. If the same photo must become square without stretched subjects, crop its composition. If dimensions are already correct but the upload is still too large, compression addresses encoded size.

A practical workflow can use more than one operation, but decide the geometry first. Preserve an original, choose the composition and dimensions needed by the destination, then evaluate whether the resulting file also needs compression or format conversion.