{"course":{"slug":"image-editing","title":"Editing an Image","url":"https://addaly.com/learn/image-editing","level":"beginner","track":"create"},"lesson":{"slug":"sizing-for-a-screen","title":"The width to export, and why the browser will not fix it for you","url":"https://addaly.com/learn/image-editing/sizing-for-a-screen","position":69,"of":78,"minutes":9,"answer":"Export width is the slot's CSS width times the device pixel ratio, capped at 2x for photographs; handing the browser a larger file costs the full bytes.","keyIdea":"Export width is the slot's CSS width times the device pixel ratio, capped at 2x for photographs; handing the browser a larger file costs the full bytes, is downscaled without gamma correction and throws away the sharpening you tuned for the output size."},"body":{"format":"markdown","text":"## Two kinds of pixel, and the number in between\n\nA layout is written in **CSS pixels**, which are a unit of apparent size, not of hardware. A phone that reports a 390-pixel-wide viewport has around 1170 physical pixels across the glass. The ratio between them is the **device pixel ratio**, and it is 1 on an old monitor, 2 on most laptops and mid-range phones, and 3 on many flagship phones.\n\nThat is the whole of the sizing arithmetic. An image displayed in a 600 CSS-pixel column needs 1200 real pixels to be crisp on a DPR 2 screen.\n\n```\nexport width = CSS width of the slot x device pixel ratio\n```\n\nWork out the CSS width honestly. It is not the width of the page, it is the width of the box the image sits in at the breakpoint you care about, which is usually the phone, because that is where most of the traffic is and where the data costs money.\n\n## Stop at 2x\n\nYou could export at 3x for the DPR 3 phones. Almost nobody should.\n\nA 3x file has 2.25 times the pixels of a 2x file, and therefore roughly 2.25 times the bytes. The visible gain over 2x on a screen held at normal reading distance is at the edge of what most people can detect, because at that pixel density the limit is your eye rather than the file. Some teams do serve 3x for logos and line art, where the hard edges do show it, and 2x for photographs. That is a defensible split.\n\nThe opposite mistake costs more. A 4000-pixel photograph dropped into a 600-pixel column is around 40 times the necessary data, and on a slow connection it is the difference between a page that loads and a page somebody leaves.\n\n## What the browser does with a mismatch, and why it is not free\n\nGive a browser an image larger than the slot and it will scale it down. People take this as a reason not to worry. Three reasons to worry:\n\n**It downloads all of it first.** The scaling is free. The bytes are not.\n\n**The downscale is not gamma-correct.** Browsers resample in encoded space, so the darkening described in the resampling lesson applies to every oversized image you hand them, most visibly on fine bright detail.\n\n**There is no output sharpening.** Your sharpening was tuned for the size you exported. Shrunk by an arbitrary factor in the browser, it is either invisible or crunchy. Resize to the delivered size yourself, then sharpen, and the result is noticeably crisper than the same photograph delivered oversized, at a fraction of the bytes. This is the single most common reason a site's images look slightly soft.\n\nThe mirror-image mistake is an image smaller than its slot, which the browser enlarges by interpolation with no detail to work from. A 400-pixel logo in an 800-pixel header is soft, and no CSS fixes it.\n\n## Numbers that are actually useful\n\nThese are starting points for a typical content site, at 2x, before you measure your own layout:\n\n- Full-bleed hero on a phone: **800 to 1000 px** wide. On a wide desktop layout, 1600 to 2000.\n- Article body image in a readable text column: **1200 to 1400 px**.\n- Card or grid thumbnail: **600 to 800 px**.\n- Avatar at 48 CSS px: **96 px**, and not one pixel more.\n- Product image with a zoom feature: the zoom is the constraint, not the page. 2000 px square is the common floor.\n\nMeasure rather than guess. In any browser, right-click an image, *Inspect*, and the element panel shows both the natural size and the rendered size. If the natural width is more than about 2.5 times the rendered width, you are wasting somebody's data.\n\n## Aspect ratio, and the shift nobody notices until it ships\n\nExport at the ratio the slot uses. If the layout crops a 3:2 photograph to 16:9 with `object-fit: cover`, the crop happens at the centre by default and it will cut heads off. Either crop deliberately in the editor and export at the target ratio, or set `object-position` so the crop favours the part that matters.\n\nAlways give the image element its `width` and `height` attributes, even when CSS resizes it. The browser uses them to reserve space before the file arrives, and without them the page jumps as each image loads: the thing that makes you tap the wrong link on a phone.\n\n## The free route\n\nNone of this needs a paid tool. GIMP's *Image > Scale Image*, Photopea's *Image > Image Size*, or one command:\n\n```bash\nmagick in.jpg -colorspace RGB -filter Lanczos -resize 1200x -colorspace sRGB \\\n  -unsharp 0x0.6+0.7+0.02 -quality 82 -strip out.jpg\n```\n\nResize, sharpen at the delivered size, compress, strip metadata. That is the whole export in one line, and the order in it is the order from the sharpening lesson.\n\nToday: open your own site or a page you made, inspect three images, and write down natural size against rendered size. The first number is usually three to six times the second, and each one of those is a file you can shrink today without anybody seeing a difference."},"check":{"question":"A designer exports every article photograph at 3000 px wide and lets CSS fit them into a 700 CSS-pixel column. The page is slow, and the images also look slightly soft compared with a competitor's. Why the softness, given that the files contain far more detail than the slot needs?","options":[{"text":"Three thousand pixels exceeds what most screens can display, so the browser must discard detail and always renders oversized images at reduced quality.","correct":false,"tempting":"Treats browser downscaling as a quality setting rather than as a resample, and implies a hardware limit that does not work that way."},{"text":"The sharpening was tuned for 3000 px, and the browser's downscale neither preserves it nor replaces it at the delivered size.","correct":true},{"text":"JPEG compression artefacts become more visible when an image is scaled down in the browser rather than in an editor.","correct":false,"tempting":"Reverses the effect: downscaling tends to average compression artefacts away rather than amplify them."},{"text":"The images are missing width and height attributes, so the browser guesses the dimensions and rounds the scaling factor.","correct":false,"tempting":"Names a real problem with a different symptom: missing dimensions cause layout shift, not softness."}]},"prev":{"slug":"resampling-algorithms","title":"Nearest, bicubic, Lanczos: what the resize dialogue is computing","url":"https://addaly.com/learn/image-editing/resampling-algorithms"},"next":{"slug":"sharpening-and-noise","title":"Sharpening adds no detail, and it goes last","url":"https://addaly.com/learn/image-editing/sharpening-and-noise"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The width to export, and why the browser will not fix it for you', in Editing an Image. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/image-editing/sizing-for-a-screen (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The width to export, and why the browser will not fix it for you","courseTitle":"Editing an Image","module":{"index":8,"slug":"out-of-the-editor","title":"Out of the editor: size, sharpness and the delivered file"},"answer":null,"keyIdea":"Export width is the slot’s CSS width times the device pixel ratio, capped at 2x for photographs; handing the browser a larger file costs the full bytes, is downscaled without gamma correction and throws away the sharpening you tuned for the output size.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"two-kinds-of-pixel-and-the-number-in-between","runs":[{"text":"Two kinds of pixel, and the number in between"}]},{"t":"p","runs":[{"text":"A layout is written in "},{"text":"CSS pixels","b":true},{"text":", which are a unit of apparent size, not of hardware. A phone that reports a 390-pixel-wide viewport has around 1170 physical pixels across the glass. The ratio between them is the "},{"text":"device pixel ratio","b":true},{"text":", and it is 1 on an old monitor, 2 on most laptops and mid-range phones, and 3 on many flagship phones."}]},{"t":"p","runs":[{"text":"That is the whole of the sizing arithmetic. An image displayed in a 600 CSS-pixel column needs 1200 real pixels to be crisp on a DPR 2 screen."}]},{"t":"code","lang":"","label":"Text","text":"export width = CSS width of the slot x device pixel ratio"},{"t":"p","runs":[{"text":"Work out the CSS width honestly. It is not the width of the page, it is the width of the box the image sits in at the breakpoint you care about, which is usually the phone, because that is where most of the traffic is and where the data costs money."}]},{"t":"h2","id":"stop-at-2x","runs":[{"text":"Stop at 2x"}]},{"t":"p","runs":[{"text":"You could export at 3x for the DPR 3 phones. Almost nobody should."}]},{"t":"p","runs":[{"text":"A 3x file has 2.25 times the pixels of a 2x file, and therefore roughly 2.25 times the bytes. The visible gain over 2x on a screen held at normal reading distance is at the edge of what most people can detect, because at that pixel density the limit is your eye rather than the file. Some teams do serve 3x for logos and line art, where the hard edges do show it, and 2x for photographs. That is a defensible split."}]},{"t":"p","runs":[{"text":"The opposite mistake costs more. A 4000-pixel photograph dropped into a 600-pixel column is around 40 times the necessary data, and on a slow connection it is the difference between a page that loads and a page somebody leaves."}]},{"t":"h2","id":"what-the-browser-does-with-a-mismatch-and-why-it-is-not-free","runs":[{"text":"What the browser does with a mismatch, and why it is not free"}]},{"t":"p","runs":[{"text":"Give a browser an image larger than the slot and it will scale it down. People take this as a reason not to worry. Three reasons to worry:"}]},{"t":"p","runs":[{"text":"It downloads all of it first.","b":true},{"text":" The scaling is free. The bytes are not."}]},{"t":"p","runs":[{"text":"The downscale is not gamma-correct.","b":true},{"text":" Browsers resample in encoded space, so the darkening described in the resampling lesson applies to every oversized image you hand them, most visibly on fine bright detail."}]},{"t":"p","runs":[{"text":"There is no output sharpening.","b":true},{"text":" Your sharpening was tuned for the size you exported. Shrunk by an arbitrary factor in the browser, it is either invisible or crunchy. Resize to the delivered size yourself, then sharpen, and the result is noticeably crisper than the same photograph delivered oversized, at a fraction of the bytes. This is the single most common reason a site’s images look slightly soft."}]},{"t":"p","runs":[{"text":"The mirror-image mistake is an image smaller than its slot, which the browser enlarges by interpolation with no detail to work from. A 400-pixel logo in an 800-pixel header is soft, and no CSS fixes it."}]},{"t":"h2","id":"numbers-that-are-actually-useful","runs":[{"text":"Numbers that are actually useful"}]},{"t":"p","runs":[{"text":"These are starting points for a typical content site, at 2x, before you measure your own layout:"}]},{"t":"ul","items":[[{"text":"Full-bleed hero on a phone: "},{"text":"800 to 1000 px","b":true},{"text":" wide. On a wide desktop layout, 1600 to 2000."}],[{"text":"Article body image in a readable text column: "},{"text":"1200 to 1400 px","b":true},{"text":"."}],[{"text":"Card or grid thumbnail: "},{"text":"600 to 800 px","b":true},{"text":"."}],[{"text":"Avatar at 48 CSS px: "},{"text":"96 px","b":true},{"text":", and not one pixel more."}],[{"text":"Product image with a zoom feature: the zoom is the constraint, not the page. 2000 px square is the common floor."}]]},{"t":"p","runs":[{"text":"Measure rather than guess. In any browser, right-click an image, "},{"text":"Inspect","i":true},{"text":", and the element panel shows both the natural size and the rendered size. If the natural width is more than about 2.5 times the rendered width, you are wasting somebody’s data."}]},{"t":"h2","id":"aspect-ratio-and-the-shift-nobody-notices-until-it-ships","runs":[{"text":"Aspect ratio, and the shift nobody notices until it ships"}]},{"t":"p","runs":[{"text":"Export at the ratio the slot uses. If the layout crops a 3:2 photograph to 16:9 with "},{"text":"object-fit: cover","code":true},{"text":", the crop happens at the centre by default and it will cut heads off. Either crop deliberately in the editor and export at the target ratio, or set "},{"text":"object-position","code":true},{"text":" so the crop favours the part that matters."}]},{"t":"p","runs":[{"text":"Always give the image element its "},{"text":"width","code":true},{"text":" and "},{"text":"height","code":true},{"text":" attributes, even when CSS resizes it. The browser uses them to reserve space before the file arrives, and without them the page jumps as each image loads: the thing that makes you tap the wrong link on a phone."}]},{"t":"h2","id":"the-free-route","runs":[{"text":"The free route"}]},{"t":"p","runs":[{"text":"None of this needs a paid tool. GIMP’s "},{"text":"Image > Scale Image","i":true},{"text":", Photopea’s "},{"text":"Image > Image Size","i":true},{"text":", or one command:"}]},{"t":"code","lang":"bash","label":"Bash","text":"magick in.jpg -colorspace RGB -filter Lanczos -resize 1200x -colorspace sRGB \\\n  -unsharp 0x0.6+0.7+0.02 -quality 82 -strip out.jpg"},{"t":"p","runs":[{"text":"Resize, sharpen at the delivered size, compress, strip metadata. That is the whole export in one line, and the order in it is the order from the sharpening lesson."}]},{"t":"p","runs":[{"text":"Today: open your own site or a page you made, inspect three images, and write down natural size against rendered size. The first number is usually three to six times the second, and each one of those is a file you can shrink today without anybody seeing a difference."}]}],"check":{"question":[{"text":"A designer exports every article photograph at 3000 px wide and lets CSS fit them into a 700 CSS-pixel column. The page is slow, and the images also look slightly soft compared with a competitor’s. Why the softness, given that the files contain far more detail than the slot needs?"}],"options":[{"text":[{"text":"Three thousand pixels exceeds what most screens can display, so the browser must discard detail and always renders oversized images at reduced quality."}],"correct":false,"tempting":[{"text":"Treats browser downscaling as a quality setting rather than as a resample, and implies a hardware limit that does not work that way."}]},{"text":[{"text":"The sharpening was tuned for 3000 px, and the browser’s downscale neither preserves it nor replaces it at the delivered size."}],"correct":true,"tempting":null},{"text":[{"text":"JPEG compression artefacts become more visible when an image is scaled down in the browser rather than in an editor."}],"correct":false,"tempting":[{"text":"Reverses the effect: downscaling tends to average compression artefacts away rather than amplify them."}]},{"text":[{"text":"The images are missing width and height attributes, so the browser guesses the dimensions and rounds the scaling factor."}],"correct":false,"tempting":[{"text":"Names a real problem with a different symptom: missing dimensions cause layout shift, not softness."}]}],"order":[0,3,1,2],"why":null},"prev":{"slug":"resampling-algorithms","title":"Nearest, bicubic, Lanczos: what the resize dialogue is computing","minutes":10},"next":{"slug":"sharpening-and-noise","title":"Sharpening adds no detail, and it goes last","minutes":9}}}