# Bad value X for attribute “width” or “height” on element “img”: Expected a digit but saw “Y” instead.
> Canonical HTML version: https://rocketvalidator.com/html-validation/bad-value-x-for-attribute-width-or-height-on-element-img-expected-a-digit-but-saw-y-instead
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
The `width` and `height` attributes of an `![]()
` take a number of pixels written with digits only, and the validator reports the first character in the value that isn't a digit.
Both attributes must hold a valid non-negative integer, such as `640`. Units, percentages, signs, decimals, spaces and any other text make the value invalid. The character in the message tells you where the number broke: in `324&height=303` it's the `&`, in `10em` it's the `e`, in `-1` it's the `-`, and in `" 300"` it's the leading space.
Values like these usually come from code, not from hand-written markup. A template that copies the image's query string (`?width=324&height=303`) into the attribute, a CMS that pastes a CSS declaration into it, or a placeholder such as `{{ width }}` that was never filled in all end up here. Browsers keep the leading digits and drop the rest, so `10em` becomes 10 pixels, not 10 em, and a value that doesn't start with a digit is ignored. Either way the browser may reserve the wrong space for the image, and the page shifts when it loads.
Write the pixel size on its own, with no unit. When the image should display at another size, or scale with the layout, set that in CSS and keep the attributes at the image's real pixel dimensions, so the browser still knows its aspect ratio.
## Invalid example
```html
```
## Valid example
```html
```