Why are odd dimensions reduced by one pixel when I resize a video?

Browser video encoders are most reliable with even pixel sizes, so odd width or height values are rounded down to the nearest even number before the frame is encoded. This avoids codec errors and edge artifacts.

Does this one-pixel loss change my video quality?

No. A single-pixel difference between 1280 and 1281, or 718 and 719, is invisible at any normal viewing size and produces a negligible change in file size.

Can I force an odd output dimension with the Video Resizer?

Not directly. The resizer always rounds odd inputs down to keep the encoder happy. Use a desktop encoder if you genuinely need an odd-pixel output.

What if I type an even number like 1282 instead of 1281?

The resizer will use 1282 exactly, since 1282 is already an even, codec-safe value. Pre-rounding your target is the simplest way to avoid the automatic one-pixel reduction.

Do Fit mode and Stretch mode round the same way?

Both modes round odd dimensions down by the same rule. Fit applies the rounding after calculating an aspect-preserving scale, and Stretch rounds the exact width and height independently.

Is the rounding visible in the output file name or metadata?

The file name is unchanged, but the actual pixel dimensions recorded in the WebM container will reflect the rounded values. Inspect the file with any media tool to confirm.

Why Odd Dimensions Lose One Pixel During a Video Resize

When you resize a video, odd dimensions are reduced by one pixel because the most common browser-based video encoders — including the VP8 and VP9 WebM codecs that power in-tab tools like the Video Resizer — only encode reliably when both the width and height are even numbers of pixels. An encoder that receives an odd dimension will either silently round it down, throw a "height not divisible by 2" or "width not divisible by 2" error, or produce a file that some players refuse to open. Rather than risk a broken download, the resizer does the rounding itself: an odd value such as 1281 becomes 1280, and an odd value such as 719 becomes 718. You still get the dimensions you typed, just rounded down to the nearest codec-safe even number. This is a standard safeguard across many video tools, not a quirk unique to your browser, and it is the same reason FFmpeg flags "width not divisible by 2" errors when you ask it to scale a clip to an odd resolution.

If you have ever watched a 1281 by 720 request come back as 1280 by 720, you have hit the alignment rule that governs every common video codec family — H.264, H.265, VP8, VP9, and AV1 all expect dimensions that are divisible by 2, and many expect multiples of 4 or 8 for the cleanest macroblock layout. The behavior is the same whether you use a desktop command-line tool, a phone app, or a browser-based resizer; what changes is whether the tool tells you about the rounding or quietly does it behind the scenes.

why are odd dimensions reduced by one pixel when i resize video — Why Odd Dimensions Lose One Pixel During a Video Resize

Why browser encoders demand even pixel dimensions

Video codecs divide each frame into rectangular blocks — typically 16 by 16 pixels for H.264, and similar macroblock-sized grids for VP8 and VP9 — so that each block can be predicted, transformed, and stored independently. When the frame width or height is an odd number, the final row or column of pixels does not fill a complete block. Older encoders rejected odd sizes outright, modern ones still struggle to encode the partial block efficiently and may produce visible artifacts at the frame edge or fail silently on capture.

To avoid those failure modes, browser recording pipelines use the canvas → captureStream → MediaRecorder chain, which is documented on MDN for both HTMLCanvasElement.captureStream and MediaRecorder. The MediaRecorder step selects a supported VP9 or VP8 WebM configuration, and the underlying codec asks the canvas for even-sized frames. The resizer rounds odd canvas dimensions down before the canvas is ever handed to the recorder, so the encoder never sees a number it cannot safely handle.

This is also why the output is always a WebM file rather than an MP4: the browser exposes VP8 and VP9 natively, while H.264 and H.265 would require a large external dependency or a server. The even-dimension rule applies to all of those codecs in the same way — it is not specific to WebM — but in a browser-only tool it is the WebM encoders that enforce it.

What happens to a 1281 by 720 resize, step by step

The rounding is straightforward once you know the rule, and you can verify it in your head before you click Resize. Take a requested size of 1281 by 720:

Width: 1281 is odd, so the resizer applies floor(1281 / 2) × 2 = 640 × 2 = 1280. Output width: 1280 pixels.
Height: 720 is already even (720 / 2 = 360 exactly), so it is not changed. Output height: 720 pixels.
Final canvas size: 1280 by 720, exactly one pixel narrower than what you typed.

The same rule applied to an odd height, say 719, gives floor(719 / 2) × 2 = 359 × 2 = 718. If you request both 1281 and 719, both dimensions lose one pixel and you receive 1280 by 718. The arithmetic is simple enough that you can predict the output size for any odd input before you start the encode, which is useful when you need a target like 1920 by 1080 and want to be sure no rounding slips in.

How to resize a video knowing odd values get rounded

The Video Resizer handles the rounding for you, so the workflow is the same as for any other resize — you only need to plan your target size so the rounded result is still the size you actually want.

Open the Video Resizer in your browser and choose one supported local video (MP4, WebM, MOV, M4V, or Ogg) up to 500 MiB and five minutes long. Wait for the browser metadata to finish loading before continuing.
Decide whether you want aspect-preserving or exact geometry. If the source ratio matters, pick Fit and enter the maximum width and height you want as a bounding box. If you need an exact rectangle and are willing to allow distortion, pick Stretch and enter the precise width and height.
Sanity-check your numbers. If either value is odd, remember that the encoder will round it down by one pixel. Type the odd value if that is still close enough to your target, or round it up yourself in advance (enter 1282 instead of 1281 if you want 1282 pixels of output, which is still even and codec-safe).
Select Resize video and keep the tab open during the real-time encode. The browser decodes the source, draws frames onto a resized canvas at up to 30 fps, captures audio tracks the browser exposes, and records the canvas through MediaRecorder.
When the recorder stops, download the resulting WebM. Confirm the actual pixel dimensions with any media inspector, and check the file plays cleanly in your target player before you delete the source.

If you want a second look at the same target size, the steps above are reproducible as long as the source and the entered dimensions stay identical. That makes it easy to confirm the rounding behavior, and it is the same reproducibility principle covered in the guide on how to repeat a video resize and get the same result.

Fit mode vs Stretch mode: how rounding affects each

Both modes feed the canvas through the same encoder, so both modes round odd dimensions down. The difference is in how the geometry is calculated before that rounding happens.

Mode	Geometry calculation	Effect on rounding
Fit (aspect-preserving)	Picks the smaller of width-scale and height-scale so the whole picture fits inside the box without cropping.	The rounded output keeps the source ratio. A single odd dimension can still shift the final size by one pixel, but the picture is not distorted.
Stretch (exact)	Uses the requested width and height independently and maps the picture onto that rectangle.	The rounded output is exactly the rounded box. Aspect distortion is intentional, and the one-pixel loss comes straight off whichever dimension was odd.

In practice, Fit is the safer mode if you only want to know how big the file will end up, because the scale is derived from the source and the rounding is predictable. Stretch is the mode to use when a target player or platform has a hard pixel requirement (for example, a 1080 by 1920 vertical export) and you are prepared to accept distortion. Either way, the one-pixel rounding rule is the same.

When the one-pixel loss matters, and when it does not

For most viewing contexts, a single pixel is invisible. A 1280 by 720 frame and a 1281 by 720 frame look identical on the same screen at the same playback size, and the file size difference is well under one percent. The loss only becomes meaningful in a few narrow cases:

Pixel-exact comparisons, such as diffing a re-encoded clip against a reference frame for quality testing.
Chained operations, where you resize, crop, and resize again — the one-pixel offsets can accumulate and leave the final file a few pixels off the target.
Hardware or codec pipelines that hard-reject odd inputs and produce a corrupted file if the metadata lies about the real frame size.

If any of those apply, type even values into the resizer from the start. Pre-emptively entering 1282 instead of 1281 keeps the output at exactly the codec-safe even size you intended, and it removes the guesswork from the workflow. For deeper preparation, the what to know before you resize a video checklist covers the surrounding decisions like source limits, audio behavior, and WebM container trade-offs.

The Video Resizer is built for fast local resizes that stay inside a browser tab, which is exactly the use case where a one-pixel loss on an odd input is the right trade-off. If you need frame-accurate delivery, a true MP4 output, exact bitrate control, or color-managed mastering, the right move is a dedicated desktop encoder that exposes the full codec configuration — the browser tool will not promise those guarantees and should not be stretched into a role it was not designed for. For the everyday job of making a clip fit a target rectangle, knowing that odd dimensions get rounded down by one pixel turns a confusing result into a predictable one.