Hero Image Size for Websites: Dimensions, File Size, and Why Your Banner Crops

Five words this guide uses

• Hero image. The large image across the top of a page, usually with a headline over it. Designers say hero; Shopify says image banner or slideshow; Squarespace says banner or section background; Wix says strip; most people say "the big picture at the top". Same thing.

• Pixels vs kilobytes. Pixels (px) are the picture's grid of dots: 1920 by 1080 means 1,920 across and 1,080 down. Kilobytes (KB) are how much the file weighs, which is what the visitor has to download. Two files can have identical pixels and very different weights, and the weight is what makes a page slow.

• Aspect ratio. The shape: width to height. 16:9 is a widescreen TV; 2.4:1 is a letterbox strip; 4:5 is a portrait phone photo. When the image's shape and the box's shape differ, something has to give, and that something is cropping.

• Device pixel ratio (DPR). A phone that is 390 "pixels" wide in your page layout is drawing those 390 layout pixels with 1,170 physical dots (3x). A 2x laptop draws a 960-wide box from 1,920 dots. So a 1920-pixel file is "full size" on a 1x monitor and "half size" on a 2x screen, which is why every sizing guide quietly disagrees with every other one.

• LCP (Largest Contentful Paint). Google's measure of how long the largest visible thing on the page takes to appear, one of the three Core Web Vitals it scores pages on. Google wants it at or under 2.5 seconds for most visits, and on a page with a hero image, the hero is usually that largest thing. If you remember one technical term from this guide, this is the one.

Size is three different things

When someone asks what size a hero image should be, the honest answer is "which size?" There are three, and most of the conflicting advice online comes from guides that quote a number without saying which one they mean.

1. The box on the page (CSS pixels). Your page lays out a hero section that is, say, the full width of the window and 600 layout pixels tall. On a 1920 by 1080 monitor at 100% scaling that is a 1920 by 600 box. On the same laptop set to 125% scaling (the second most common desktop setup in StatCounter's September 2026 data, which reports it as 1536 by 864) the box is 1536 by 480 layout pixels, drawn with 1920 by 600 physical dots. On a phone it is 390 by maybe 500, portrait. You do not control the box's size; the visitor's screen does. You only control its shape, through the theme setting that fixes the section height.

2. The pixels in the file. This is the number every guide gives, and what most people mean by hero image resolution: 1920 by 1080, 2500 wide, 800 by 1200. The browser scales the file to fit the box, so a 1920-wide file fills a 1920 box at 1x exactly, fills a 960-wide 2x box at full sharpness, and gets scaled down to fit a 390-wide phone (a 4000-pixel camera JPEG would be scaled down just the same, having sent ten times the bytes for no visible gain).

3. The weight of the file (kilobytes). This is the one that decides whether the page feels fast, and it depends on the pixels and on the format and quality you saved it in. The same photograph weighed 1.79 MB as it came off a phone, 822 KB saved as a JPEG at 1920 by 1080, 438 KB as an AVIF at the same pixels, and 246 KB as an AVIF at a lower quality setting that we could not tell apart from the original at 1:1 (our run, section 5). Nobody has ever noticed the difference between a 1920 and a 2500-pixel hero on a laptop; everybody notices a page that takes four seconds to show its picture.

Hold those three apart and the rest of this guide is simple: choose the shape to match the section (so it does not crop badly), choose the pixels to cover the box on the screens you care about (so it does not blur), and choose the format and quality to make the weight small (so it loads fast).

Why your hero image crops and zooms

Your hero crops because the section's shape is fixed by your theme and the hero image aspect ratio is fixed by you, and when they differ the theme shows as much of the image as fits and cuts off the rest. No pixel size fixes that; only the shape does, plus where you put the subject.

This is the complaint behind most of the forum threads that rank for hero image size: "on desktop my image is cut and too much zoomed", "I tried the recommended dimensions and it zooms in", "it looks great on mobile but on PC it is in your face", "I made several sizes and all of them get cropped". Shopify's own help page describes the mechanism plainly for any hero section background image: slideshows, image banners and full-width sections "display images in an image area whose shape is set by the section, not by the image that you upload", and "if your image's aspect ratio is different from the aspect ratio of that area, then the section crops the image to fit" (Shopify Help Center, Uploading images). Every builder works the same way; in CSS terms the image is set to cover the box (object-fit: cover or background-size: cover), which keeps its shape and clips whatever hangs over the edge.

Follow one photo through it. You upload a 1920 by 1080 landscape of a workshop, with the product on the left and the owner on the right. On a wide monitor the banner section is 1920 by 600 (3.2:1): the browser scales the image to fill the width, which makes it 1,080 tall, and clips 240 pixels off the top and 240 off the bottom. The owner's head is gone. On a phone the box is 390 by 520, portrait: the browser scales the image to fill the height, which makes it 924 wide, and shows the middle 390 of those 924 pixels. Both the product and the owner are gone; the visitor sees the wall between them. That is "zoomed in". Nothing was enlarged; the box simply cannot show the whole picture, so it shows the middle.

Three rules follow, and they are the ones the platforms' own documentation gives:

1. Match the image's shape to the section, or set the section to match the image. Most themes let you pick a banner height (small, medium, large, or one that adapts to the image's own ratio). The adaptive option never crops on desktop; the fixed heights always can. If a theme section is 16:9, upload 16:9.

2. Keep the subject in the middle, and keep the edges expendable. A wide image loses its left and right on phones; a tall one loses its top and bottom on monitors (Shopify's page says exactly this). Our working rule: put the subject, and anything you cannot lose, inside the middle half of the width and the middle two-thirds of the height. Shopify and Wix let you set a focal point on the image so the crop centers on it; set it.

3. Never put text in the image. Shopify's guidance: "images that you use for slideshows or backgrounds shouldn't have text in them", because the theme crops, moves and resizes the image under the text. A Squarespace owner on the support forum whose banner had the headline "burned in" found it illegible on phones for exactly this reason. Put the headline in the section's own text field, where it reflows.

For phones, the better answer is a second image. A portrait crop of the same photo, with the subject filling the frame, looks like a choice rather than an accident. Most themes and every custom site can show a different image below a certain width; section 7 shows the <picture> version for sites you build yourself, and the platform section says where each builder keeps the mobile setting.

When this is not your problem: if your hero is a plain color, a gradient or an illustration with nothing important near the edges, cropping is harmless and you can skip the mobile crop. Just keep the weight down.

Hero image size by layout: desktop, banner and mobile dimensions

The right website hero image size is 1920 pixels wide for any full-width desktop hero, at the height your section's ratio needs; upload a separate portrait image around 1080 pixels wide for phones; and go to 2560 wide only when you have measured that the sharper file is worth its extra weight. Those three hero image dimensions cover almost every site, and here is where they come from.

Why 1920. StatCounter's worldwide screen data for September 2026 puts 1920 by 1080 at 28% of desktop screens, with 1536 by 864 (a 1920 laptop at 125% scaling) at 10%, 1366 by 768 at 8%, and 2560 by 1440 at 4% (StatCounter, desktop resolutions). A 1920-wide file is full sharpness on the first three, which between them are most desktop visits, and it is scaled down, never up, on everything smaller. On the 2560 monitor it is stretched by a third; on a 2x laptop (a 1440-wide layout drawn with 2880 dots) it is stretched by a half. Both look fine for a photograph. The eye forgives a scaled-up photograph far more readily than a scaled-up screenshot or logo.

Heights follow the section, not a rule. The full screen hero image size on a 16:9 monitor is 1920 by 1080. A banner that sits above the content wants something wider and shorter: 1920 by 800 (2.4:1) and 1920 by 640 (3:1) are the common shapes, and they are what the "1600 by 500" and "1200 by 400" figures in older guides are approximating. Measure your own section: open the page, right-click the hero, choose Inspect, and read the box's width and height at the top of the panel. Upload at that ratio.

When to go to 2x. A 2x file (3840 wide for a 1920 box, 2560 wide for a 1280 box) is sharper on retina screens, and twice to four times the weight. Go there only if the hero is a product shot, typography or line art where softness shows, your audience is heavily on high-density screens, and the AVIF still comes in under budget. For a photograph of people, a landscape or a workshop, 1920 is enough and the saved bytes are worth more than the sharpness nobody noticed. Two platform facts put a ceiling on it anyway: WordPress scales any upload with a side longer than 2560 pixels down to 2560 before it is ever served (the "big image" threshold, WordPress 5.3), and Squarespace's largest generated variant is 2500 wide (Squarespace Support, Formatting images). Uploading 4000 pixels to either gets you a 2500-pixel file and a slower upload.

Mobile hero image size: a separate crop, about 1080 wide, portrait or square. Phones in StatCounter's top five are 360 to 414 layout pixels wide, drawn at 2x to 3x, so a file 800 to 1,170 pixels wide is full sharpness on all of them. The usual recommendation is 1080 by 1350 (4:5) or 1080 by 1440 (3:4); both fill a phone's hero area with no side cropping. Keep the subject central here too, because phones vary in height and the box will still trim top and bottom.

What about 2500, 3000, 1600? Squarespace recommends uploading 2500 wide because it makes its own seven sizes from your upload (100 to 2500 wide) and warns that images under 1500 may look blurry; Wix asks for at least 3000 by 3000 for section backgrounds; theme vendors print 1600 by 500 or 3000 by 1500 from their own measurements. None of them conflict with the numbers above once you know which of the three sizes they are talking about: the big uploads are the platform asking for a master it can resize from, and the serving sizes are what the visitor gets. Where you control the file the visitor receives, 1920 is the number.

File size: what a 1920-pixel hero weighs in JPEG, WebP and AVIF

A 1920 by 1080 hero photograph lands between about 250 KB and 500 KB as an AVIF or a modern JPEG depending on how much fine detail is in it, and "under 200 KB", the figure every sizing guide repeats, is a budget you reach by choosing the quality setting, not a number the format hands you for free. What the guides leave out is that a kilobyte target only means something at a stated pixel size and format, and that the picture itself decides most of it: a sky, a wall or a product on white compresses to a fraction of what a tree does.

We measured it on October 15, 2026, with a deliberately hard subject: a 2576 by 1932 iPhone photograph of a garden under a cherry tree, 1.79 MB as it came off the phone, almost entirely leaves, grass and twigs, with no flat areas for an encoder to save on. Every step below went through Mochify's API with the quality left on automatic unless stated; the baselines are the same pixels saved as an ordinary JPEG at quality 85, which is the file a careful person would upload.

• Pixels first. Resizing the full frame from 2576 to 1920 wide took the JPEG from 1.79 MB to 1.05 MB. Cropping it to the 16:9 shape a full-screen hero section actually shows (1920 by 1080) took it to 822 KB. That is 54% gone before any format question arises, and it is the step people skip because the platform "resizes it anyway". It does, for display; it does not always re-encode the file it serves, and it never fixes a file that was heavy at 1920 to begin with.

• Format second. At 1920 by 1080 and automatic quality, the 822 KB JPEG came back as a 438 KB AVIF (47% smaller), a 463 KB JPEG re-encoded with jpegli (44% smaller) and a 517 KB WebP (37% smaller). Two things worth noticing: AVIF won, as it usually does on photographs, and a modern JPEG encoder beat WebP, which means "convert to WebP" is not automatically a saving over a well-made JPEG. Support is no longer the question: caniuse's September 2026 data has AVIF at 96.35% of global users and WebP at 97.18% (caniuse, AVIF). Keep a JPEG as the fallback for the last few percent, and if JPEG is all your platform will take, make it with a modern encoder: Google's jpegli produces standard JPEG files that open everywhere and are, in Google's words, "35% more" compressed than traditional JPEG at high quality (Google Open Source Blog, April 2024).

• Quality last, and this is where the 200 KB comes from. The automatic setting is tuned for "nothing visible lost", and on this picture that is 438 KB. Asking for AVIF at quality 45 instead gave 246 KB, 70% below the JPEG baseline. We then put a 1:1 crop of the busiest patch of foliage from the baseline, the automatic AVIF and the quality-45 AVIF side by side and could not find a difference. That is one region of one image checked by one pair of eyes, so do your own check at the size the hero is shown, but it is the general shape of the result: on a hero, the gap between "automatic" and "half the bytes" is usually invisible, and the gap between quality 85 and 95 is always invisible and often doubles the file.

The same photo at the sizes a srcset would serve (section 7): at 800 by 600 the baseline JPEG was 198 KB and the AVIF 110 KB, so the phone file is where a 200 KB budget is met without touching the quality at all.

For scale: the HTTP Archive's 2024 Web Almanac found that 48% of mobile sites served an LCP image of 100 KB or less, which means the top half of the web is already under budget and the bottom half is where the four-second heroes live (Web Almanac 2024, Performance). The three levers, in the order they pay:

1. Pixels first. Resizing a 4000-pixel camera file to the 1920 the page shows removes three quarters of the pixels before any format question arises. This is the biggest single saving on most sites and the one people skip, because the platform "resizes it anyway". It does, for display; it does not always re-encode the file it serves, and it never fixes a file that was 2 MB at 1920 to begin with.

2. Format second. At the same pixels and the same visible quality, WebP and AVIF are roughly half the weight of a JPEG, and AVIF is usually the smaller of the two on photographs. Support is no longer the question: caniuse's September 2026 data has AVIF at 96.35% of global users and WebP at 97.18% (caniuse, AVIF). Keep a JPEG as the fallback for the last few percent, and if JPEG is all your platform will take, encode it with a modern encoder: Google's jpegli produces standard JPEG files that open everywhere and are, in Google's words, "35% more" compressed than traditional JPEG at high quality (Google Open Source Blog, April 2024).

3. Quality last. The difference between "quality 85" and "quality 95" is invisible on a hero and often doubles the file. Let the encoder choose, check the result at the size it is shown, and only then adjust.

Two things that do not help: PPI or DPI (print settings that have no effect on screen rendering or on file weight, as Squarespace's support page states plainly), and "lossless" (pixel-exact encoding is for screenshots and diagrams; on a photograph it makes a larger file than the JPEG you started with).

The slow page: the hero is your LCP image

If your page feels slow to show its top picture, that is Largest Contentful Paint, and the hero is the element being measured. Google scores LCP as good at 2.5 seconds or less and poor above 4 seconds, measured at the 75th percentile of real visits on mobile and desktop separately (web.dev, Largest Contentful Paint). Images, including an element with a CSS background image, count; so does a block of text, which is why a hero with a big headline and a slow photo sometimes scores on the headline instead. In 2024, 59% of mobile pages and 74% of desktop pages passed, so a failing hero puts you with the 41% of mobile pages that did not, and the fix is usually the file in the previous section plus one of the serving rules in the next.

See it yourself, click by click. Open pagespeed.web.dev, paste your page's address, and run the analysis. Stay on the Mobile tab (that is where sites fail). Scroll to the diagnostics and find the one titled Largest Contentful Paint element: it names the element (with a snippet of its HTML, so you can see whether it is your hero's <img>) and breaks its time into four parts. If the element is your hero image and the number is red or orange, this guide is the fix. If the element is a block of text, the hero loaded after the text painted, which is its own kind of slow (see "not discoverable" below).

The four parts, in plain English. Google splits an image's LCP time into: the time until the server sends the page at all (TTFB); the delay before the browser even starts fetching the image (resource load delay); the download itself (load duration); and the wait between the download finishing and the picture being drawn (render delay). web.dev's guidance is that the download should be about 40% of the total and the delay before it starts under 10%, and its own research found that "websites spend more time on resource load delay than on load duration" (web.dev, Optimize LCP). In other words: a heavy file is the usual problem, but a file the browser did not know to fetch early is nearly as common, and the 2024 Almanac counts 35% of mobile sites whose LCP element is not discoverable in the HTML at all. That is the CSS-background problem, and section 7 is about it.

What a good result looks like. To improve LCP on a page whose largest element is the hero, this is the target: hero as an <img> in the HTML, 1920 wide, AVIF or WebP at a few hundred kilobytes with a JPEG fallback, marked high priority, not lazy-loaded, with its width and height declared so the page does not jump when it arrives (that jump is a second Core Web Vital, CLS, which Google wants at 0.1 or less and which "images or videos with unknown dimensions" cause). Do that and the hero's share of LCP is the download of one small file that starts the moment the page arrives.

Serving it right: <img>, fetchpriority, srcset and <picture>

Put the hero in the HTML as an <img> with fetchpriority="high", never lazy-load it, declare its width and height, and give the browser a smaller file for phones with srcset or a different crop with <picture>. That is the whole list; here is each one with the simplest form first.

Use <img>, not a CSS background. A background image lives in a stylesheet, so the browser only discovers it after it has downloaded and read the CSS, then started the image. An <img> is in the HTML itself, so the fetch starts while the page is still arriving. web.dev's rule is that an LCP image that is a CSS background is "not discoverable" unless you add a preload for it, and that "preload is still required for early discovery of LCP images included as CSS backgrounds" (web.dev, Fetch Priority). If your theme forces a background (many page-builder "section background" settings do), the preload line below is the patch; moving the hero to an image block is the fix.

<img src="hero-1920.jpg" alt="The workshop at opening time"
     width="1920" height="800" fetchpriority="high">

Three attributes do the work. width and height let the browser reserve the right space before the file arrives (MDN says this "reduces or even prevents a layout shift"); they are the file's pixels, and CSS can still scale the box. fetchpriority="high" tells the browser to fetch this image ahead of the others; web.dev's test on Google Flights moved LCP from 2.6 s to 1.9 s with that one attribute, and it is supported in Chrome and Edge since 102, Safari since 17.2 and Firefox since 132. Set it on one image, the hero; on three it stops meaning anything. And note what is not there: no loading="lazy". web.dev's wording is "never lazy-load your LCP image", yet 16% of mobile sites still did in 2024. Many themes add lazy loading to every image including the first; if yours does, remove it from the hero.

The broken case, and its fix. The hero is set as the background of a <section> in the theme's CSS, the page scores a 3.8 s LCP, and PageSpeed names the section. You cannot change the markup. The patch is a preload in the <head>, which tells the browser about the file before it has read the CSS:

<link rel="preload" as="image" href="hero-1920.avif" type="image/avif" fetchpriority="high">

That brings discovery forward and usually takes a second off. It is still worse than an <img>, because a preload names one file for every screen; our Quick Answer on fetchpriority versus preload for the LCP image covers when you need both and when the attribute alone is enough, and WordPress users have a preload walkthrough for AVIF heroes.

Smaller files for smaller screens: srcset and sizes. A phone does not need the 1920-pixel file. With srcset you list several widths of the same image and tell the browser how wide the box will be; it picks the smallest file that is sharp on that screen (MDN: with width descriptors "the browser uses those descriptors together with the sizes attribute to pick a resource").

<img src="hero-1920.jpg"
     srcset="hero-800.jpg 800w, hero-1280.jpg 1280w, hero-1920.jpg 1920w"
     sizes="100vw"
     alt="The workshop at opening time" width="1920" height="800" fetchpriority="high">

Follow a visitor through it. On a 390-wide 3x phone the box is 390 layout pixels, so the browser wants about 1,170 image pixels and takes hero-1280.jpg. On a 1x 1920 monitor it takes hero-1920.jpg. On a 2x 1440 laptop it wants 2,880 and takes the largest you offered, 1920, scaled up a little. The same photograph is served at three weights and nobody sees a difference. sizes="100vw" means "the box is the full window width", which is true for a full-bleed hero; a hero inside a 1200-pixel container would say sizes="(min-width: 1200px) 1200px, 100vw".

A different crop for phones: <picture>. srcset changes the size; it cannot change the shape. For the portrait phone crop from section 3 you wrap the <img> in a <picture> with a media condition, and the same wrapper is how you offer AVIF and WebP with a JPEG fallback:

<picture>
  <source media="(max-width: 767px)" srcset="hero-phone-1080.avif" type="image/avif">
  <source media="(max-width: 767px)" srcset="hero-phone-1080.jpg">
  <source srcset="hero-1920.avif" type="image/avif">
  <img src="hero-1920.jpg" alt="The workshop at opening time"
       width="1920" height="800" fetchpriority="high">
</picture>

The browser reads top to bottom and takes the first source it can use, so phones get the portrait AVIF, everything else the landscape AVIF, and anything that cannot open AVIF falls to the JPEG. The attributes stay on the <img>; the <picture> is only a wrapper. The rules that make this render, the source order for 2026, and the WebP line we left out here for brevity are in our guide to the HTML picture tag.

Verify it, click by click. Open the page in Chrome, right-click, choose Inspect, open the Network tab, click the Img filter and reload. The first image in the list should be your hero, its Priority column should read High (right-click a column header to show Priority if it is hidden), and its Size column should be the figure you budgeted. Shrink the window to phone width and reload: the phone file should appear instead. If the hero is not near the top of the list, the browser found it late (a CSS background, or lazy loading); if the size is large, the file section is where to go back to.

When none of this is needed. A hosted builder adds most of it for you: WordPress has set fetchpriority on the likely LCP image since 2023 (the Almanac credits that for adoption jumping from 0.03% to 15% of mobile sites) and has generated srcset since version 4.4; Squarespace and Webflow generate the size variants and the srcset on upload. On those platforms your job is the file and the crop, and the markup is theirs; check it in the Network tab once, then leave it.

Platform workflows: WordPress, Shopify, Squarespace, Wix, Webflow

Every builder resizes your upload for display; none of them will fix a file that was too heavy at the pixels it needs, and each crops by its own rules. Here is what each one does, from its own documentation, and what you still have to do.

WordPress hero image size

WordPress makes several sizes of every upload (150, 300, 768 and 1024 wide by default, plus your theme's own), serves them with srcset and sizes since version 4.4, and scales any image with a side over 2560 pixels down to 2560 on upload. Since 2023 core also sets fetchpriority="high" on the image it judges likely to be the LCP element. So the markup is largely done for you, and the work is the file: resize the hero to 1920 (or 2560 if you want a 2x master; anything larger is wasted), convert it to AVIF or WebP, and upload that. Core does not convert formats itself; our guides on fixing the "next-gen formats" warning in WordPress and on what WordPress 7.1 optimizes without a plugin cover the routes. Two checks: if a theme or plugin lazy-loads every image, make sure the hero is excluded; and if the hero is a block or page-builder background, it is a CSS background with the discovery problem above, so prefer an image block or add the preload.

Shopify hero image size

Shopify accepts uploads up to 20 MB and about 20 megapixels (its help pages give both 20 MP and 25 MP / 5000 by 5000 as the ceiling; stay under 20), recommends 2048 by 2048 for square product images, and crops banner and slideshow images to the section's shape, as quoted in section 3. There is no official pixel size for the Dawn or Horizon hero sections, whatever third-party guides print; the honest answer is "the ratio your banner height setting produces", which you find by inspecting the rendered section. Upload 1920 wide at that ratio, set a focal point on the image so the crop centers on the subject, and keep text out of the image and in the section's text fields. Shopify's CDN can serve resized variants to the theme, so phones need not get the full file; what it serves is derived from your upload, so upload a file that is already under budget at 1920 rather than a 6 MB original. Some themes offer a separate mobile image for banners; where yours does, use it for the portrait crop.

Squarespace hero image size

Squarespace Support asks for 2500 pixels wide, warns that images under 1500 wide may look blurry on computers, recommends 500 KB or less for speed, accepts .jpg, .png, .gif and .webp up to 20 MB and 120 megapixels, and makes seven widths from your upload (100 to 2500) to serve by screen size. It also says, correctly, that DPI and PPI "only affect an image's print quality, not its web display". So: upload a 2500-wide master in WebP (AVIF is not on the accepted list) at a weight well under 500 KB, match the image's shape to the section's, and set the focal point so the mobile crop keeps the subject. Squarespace's own blog quotes hero files of 10 to 20 MB, which is the upload limit, not a target; its support page's 500 KB is the number to work to.

Wix hero image size

Wix converts images to AVIF on the live site automatically, accepts uploads up to 50 MB, and asks for at least 3000 by 3000 for section backgrounds (Wix, supported media file types). A strip's image setting of "Scale to Fill" crops to the strip's shape, with a grid for choosing the focal point. Because Wix handles the format and the resizing, your lever is the shape and the focal point: match the image to the strip, pick the focal point, and check the strip in the mobile editor view before publishing. Do not upload a 50 MB file because you can; a clean 2500-wide master under a megabyte is plenty for Wix to derive from.

Webflow hero image size

Webflow limits image uploads to 4 MB and generates up to seven variants (3200, 2600, 2000, 1600, 1080, 800 and 500 wide) with srcset and sizes for images added through the designer, but not for background images and not for images added by CSV or API (Webflow Help, Responsive images). The 4 MB limit means you are resizing and compressing before upload anyway; do it to 1920 or 2560 and AVIF or WebP. And because the variants do not apply to backgrounds, put the hero in an Image element rather than a section background, or you get one file for every screen and the discovery delay on top.

When your hero is a video

An autoplaying video hero has the same problem as an oversized image, usually worse: a heavy MP4 has to start downloading and decoding before the browser can paint anything, and the poster image, if there is one, is what LCP measures. Treat the poster as the hero (everything above applies to it), keep the clip short and muted, and convert it to WebM, which is smaller at the same quality in every browser that matters. Our guide to converting MP4 to WebM for the web covers the settings, and the MP4 to WebM converter runs in your browser, so the video never leaves your device. Video is the one Mochify format that is processed on-device; images are not, and the next section says so.

Mochify Workflow: resize, convert and compress a hero in one prompt

The fastest way to get a hero to the right pixels, format and weight is to describe the result rather than configure it. Mochify's Magic Flow takes a plain-English instruction and applies the resize, the format and the quality in one pass; the same engine is behind the CLI for a folder of images and the Chrome extension for a single image on a page.

Metadata. Camera files carry EXIF (camera model, GPS position, timestamps), which adds weight and leaks where the photo was taken. Mochify strips it by default on every path above (the API unless you send stripExif=false, the CLI unless you pass --keep-metadata); for a hero on a public page that is what you want. Our guide to EXIF data and the risks of leaving it in has the detail.

Privacy, for this workflow. Images travel to api.mochify.app over HTTPS, are streamed into the encoder in memory, and are wiped the moment the encode finishes: no disk writes, no logs containing file data, and never used to train AI. That holds for the web app, the CLI and the extension alike; the CLI writes the result to your disk and nothing is kept on the server. Video, as above, is processed in the browser and never leaves your device.

Cheat Sheet

FAQ