Email Header Dimensions & Mobile Crop Checklist
# Email Header Dimensions & Mobile Crop Checklist
Get exact pixel specs, safe zone rules, and a repeatable pre-send checklist for email headers that render cleanly on mobile. Check your dimensions before you send. Export a production-ready header graphic that stays sharp on retina screens.
- Standard container width: 600–640px
- Mobile safe text zone: Center 320px
- Retina-ready export density: 2x resolution
You finalize the header. It looks clean at 600px on your monitor — logo centered, tagline readable, CTA visible. You send a test to your phone and the logo is half-gone, the tagline wraps into the button, and the offer deadline is buried below the fold. This is not a rare edge case. It is the default outcome when header art is built to desktop assumptions and shipped without a mobile crop verification step.
The core tension is dimensional. A desktop email container sits at 600–640px wide, but the same template on a 320px mobile viewport scales the header image down to roughly half that width. Any text or logo element placed near the horizontal edges of the desktop canvas can disappear entirely on the narrowest common mobile screens. Height compounds the problem: a header taller than 200px pushes body content below the fold on portrait mobile, and some clients apply their own viewport clipping on top of that.
Then there are the failure modes that have nothing to do with dimensions at all. Outlook blocks images by default, so a header with no background color fallback and no descriptive alt text renders as a blank white rectangle. Many email clients, including Outlook, block images by default, meaning the header's message must survive without the image entirely. Dark mode in Apple Mail and Gmail can invert or recolor text embedded in images, making white-on-dark headlines suddenly invisible. Retina screens on modern iPhones expect a 2× asset, so a header exported at exactly 600px will look soft unless the source file is 1,200px wide and constrained with a max-width declaration.
# Email Header Dimensions & Mobile Crop Checklist
Get exact pixel specs, safe zone rules, and a repeatable pre-send checklist for email headers that render cleanly on mobile. Check your dimensions before you send. Export a production-ready header graphic that stays sharp on retina screens.
At a glance
- Standard container width: 600–640px
- Mobile safe text zone: Center 320px
- Retina-ready export density: 2x resolution
The Email Header Dimensions & Mobile Crop Checklist Every Designer Needs in 2026
You finalize the header. It looks clean at 600px on your monitor — logo centered, tagline readable, CTA visible. You send a test to your phone and the logo is half-gone, the tagline wraps into the button, and the offer deadline is buried below the fold. This is not a rare edge case. It is the default outcome when header art is built to desktop assumptions and shipped without a mobile crop verification step.
The core tension is dimensional. A desktop email container sits at 600–640px wide, but the same template on a 320px mobile viewport scales the header image down to roughly half that width. Any text or logo element placed near the horizontal edges of the desktop canvas can disappear entirely on the narrowest common mobile screens. Height compounds the problem: a header taller than 200px pushes body content below the fold on portrait mobile, and some clients apply their own viewport clipping on top of that.
Then there are the failure modes that have nothing to do with dimensions at all. Outlook blocks images by default, so a header with no background color fallback and no descriptive alt text renders as a blank white rectangle. Many email clients, including Outlook, block images by default, meaning the header's message must survive without the image entirely. Dark mode in Apple Mail and Gmail can invert or recolor text embedded in images, making white-on-dark headlines suddenly invisible. Retina screens on modern iPhones expect a 2× asset, so a header exported at exactly 600px will look soft unless the source file is 1,200px wide and constrained with a max-width declaration.
This page addresses all of it in one place: a precise dimension reference, per-client safe-zone guidance, fallback behavior specifications, and a numbered pre-send checklist you can copy and run before every campaign.
Email Header Dimension Specs at a Glance: Desktop, Mobile, and Retina in One Chart
Before you open a design file, lock in the numbers. The table below consolidates the specifications you need to size a header that renders cleanly across desktop clients, mobile portrait viewports, and high-DPI screens — without retrofitting after a test send reveals a crop problem.
The retina relationship explained. Exporting your header at 1,200 px wide and constraining it in HTML with `max-width: 600px` tells a retina display to map two image pixels to every one CSS pixel — producing a sharp render. The critical detail designers miss: this 2× export does not change the rendered crop boundary. The email client still crops to the 600 px container width and whatever height your `<img>` tag or CSS height property allows. A 1,200 × 400 px export displayed at `max-width: 600px` with no explicit height will render at 600 × 200 px — exactly half the export dimensions. If your safe-zone text sits at pixel row 380 in the export, it maps to rendered row 190, which falls inside a 200 px tall header. If it sits at row 420, it is clipped. Design the asset at 1,200 px wide and treat 600 px as the rendered canvas when placing text and logos.
Decision point — when to use 640 px instead of 600 px. If your audience skews heavily toward Outlook on Windows, stay at 600 px. Outlook uses the Word rendering engine and behaves unpredictably at non-standard widths. For modern ESP-built templates targeting Gmail and Apple Mail, 640 px gives marginally more horizontal breathing room without introducing horizontal scroll risk.
Safe Zone Breakdown: Exactly Which Pixels Get Cropped on iOS Mail, Gmail Android, and Outlook Mobile
Generic dimension tables tell you a header should be 600px wide. They rarely tell you which 600px survives intact after each mobile client finishes rendering it. The three clients below each impose a different constraint, and designing to the most forgiving one means your header will fail on the others.
iOS Mail (iPhone 14/15, portrait) iOS Mail scales the full 600px template down to fit the device viewport, typically around 390px wide on modern iPhones. That proportional scale means a 600×200px header renders at roughly 390×130px. No horizontal crop occurs, but vertical content compresses. Any text placed below the vertical midpoint of the image risks becoming too small to read without a zoom gesture. Safe zone for legible text: horizontally centered, occupying no more than 60% of the image width, and positioned in the upper 55% of the image height.
Gmail Android (default app, standard Android viewport) Gmail Android enforces a hard container width — commonly 360px on mid-range devices — and does not always scale images proportionally when fluid width declarations are absent. If your header image lacks `width: 100%; max-width: 600px;` in its inline styles, Gmail may render it at its native 600px and clip the right edge entirely. The practical safe zone: keep all logos and critical text within the central 280px horizontal band, treating the outer 160px (80px per side) as bleed-only territory on this client.
Outlook Mobile (iOS and Android) Outlook Mobile generally respects fluid scaling but applies its own padding inside the reading pane — typically 12–16px per side — which effectively narrows the visible area by 24–32px total. On a 360px viewport, that leaves roughly 328px of usable width. More critically, Outlook Mobile on Android has been observed clipping the bottom of tall hero images when the image height exceeds the initial viewport without a defined `max-height` or explicit table cell height. Keep hero height at or below 180px to avoid this edge case.
The checklist implication: Each of these behaviors is a discrete verification point. Before every send, confirm your header image carries `width: 100%; max-width: 600px;` inline, that no logo or headline text sits outside the central 280px horizontal band, and that image height stays within 180px if your audience includes Outlook Mobile users. Gmail Android's horizontal clip is the most destructive failure mode; design to that constraint first, then verify iOS Mail scaling and Outlook Mobile padding do not push text below readable size.
The Pre-Send Mobile Crop Checklist: 10 Steps to Run Before Every Email Campaign
Run these steps in order. Each maps to a specific failure mode. Check the box only when you have verified the condition visually in a rendered preview, not just by reading the spec.
1. Confirm container width is 600px. Set the email container to exactly 600px. 600px is the industry standard that renders cleanly in Gmail, Outlook, Yahoo, Apple Mail, and on mobile without horizontal scrolling. If your template uses 640px, verify that your header image fills the container without leaving white gaps on either side.
2. Verify header height is within the 150–200px range. Recommended header height is 150–200px for most email types, up to 250px for brand-led campaigns. Measure the rendered height in your preview tool, not the source file. A 300px header on a 667px iPhone viewport consumes nearly half the visible screen before the body begins.
3. Export the header image at 1,200px wide, displayed at 600px. Design image assets at 1,200px wide and set the displayed width to 600px so the image renders at 2× resolution on retina screens. Apply `max-width: 600px; width: 100%;` in the image tag. Without the max-width constraint, the 1,200px source file will overflow the container on desktop clients that do not scale images automatically.
4. Keep all critical text and logos inside the horizontal safe zone: 80px inset from each edge at 600px. At 320px mobile, the header scales to 53% of its desktop width. An element sitting 40px from the left edge at 600px lands at roughly 21px from the edge at 320px — survivable. An element at 20px from the edge at 600px can clip under the device chrome. Keep logos, taglines, and CTA labels inside a centered 440px-wide zone on the 600px canvas.
5. Check focal point centering for AI-generated or photographic hero images. If the header uses a generative or photographic background, confirm the primary subject sits within the center 50% of the canvas width. Mobile scaling is proportional, but some clients apply `object-fit: cover` behavior that crops edges before scaling. A face or product placed at 80% from the left on a 600px canvas may not survive a 320px render.
6. Confirm file size is under 200KB for JPEG/PNG headers. Header image file size should be under 200KB, ideally under 100KB. Use JPEG for photographic headers; use PNG when the header contains a logo, text overlay, or transparent element. GIF headers should stay under 500KB.
7. Set a background color on the header cell that matches or complements the image. When images are blocked, the header cell should not go white. Set `background-color` on the containing `<td>` to the dominant color of the header image. This preserves visual hierarchy even without the image loading.
8. Write alt text that communicates the header's message in under 100 characters. Descriptive alt text ensures the header's message communicates when the image does not load. Write alt text as a functional sentence, not a file description. "50% off all orders — ends Friday" is useful. "header_v3_final.jpg" is not.
9. Test legibility in dark mode at 320px and 600px viewports. Apple Mail and Gmail on iOS can invert or recolor image-embedded text under dark mode. If your header uses white text on a dark background baked into the image, preview it in dark mode. If the client inverts the image, white text on dark becomes dark text on light — potentially invisible against a light background. Consider using HTML text over a CSS background instead of text embedded in the image file.
10. Verify the preheader text is set and runs 50–100 characters. Preheader text should be 50–100 characters; mobile preview truncates further, with a maximum of approximately 140 characters. The preheader is the first text a mobile recipient reads before opening. If it is empty, the client pulls the first HTML text in the body — often an unsubscribe link or alt text string.
If you use a visual asset tool like Veeso AI to produce editable header artwork, you can apply safe-zone overlay guides directly on the canvas before export, which makes steps 4 and 5 faster to verify without switching between design and preview environments.
Fallback Behavior Specs: What Your Header Must Do When Images Are Blocked
Image blocking is not an edge case. Outlook blocks images by default, and a significant share of corporate recipients never enable them. Treating fallback behavior as an optional polish step means a large portion of your audience sees a blank rectangle where your header should be. The following specifications define what the header region must communicate without any image loading at all.
Background-color fallback. Every header image cell needs a `bgcolor` attribute and an inline `background-color` CSS value set to your brand's primary hex color. Use both because Outlook reads the HTML attribute while modern clients read the CSS property. If your header image uses a dark navy background with white text, set `bgcolor="#0D1F3C"` so the region reads as intentional rather than broken when the image is absent. Choose a color that makes your alt text legible — light background requires dark alt text color, set via inline `style="color:#FFFFFF"` on the `<td>` or a wrapping element.
Alt text character limits and content rules. Descriptive alt text on header images ensures the header's message communicates even when the image does not load. Keep alt text for a header image to 60–80 characters — enough to convey the offer or brand identity, short enough to avoid wrapping awkwardly inside a narrow header cell. For a promotional header, write the alt text as a compressed version of the headline: `"Spring Sale — 30% off sitewide, ends Sunday"` rather than `"email header image"`. The latter tells a blocked-image recipient nothing useful.
Bulletproof button placement. If your header contains a CTA, do not embed it inside the image. Build it as a bulletproof HTML button — a table-based anchor with inline background-color, border, and padding — positioned below the image cell but still within the header region. CTA buttons should be 200–300 px wide and 50–75 px tall, and full-width on mobile. This button renders in every client regardless of image-blocking status, and it provides a tap target that meets the 44 × 44 px minimum even when the surrounding header image is invisible.
Checklist verification step. Before every send, disable images in your email preview tool and confirm three things: the background color fills the header region correctly, the alt text reads as a coherent message, and the CTA button is visible and tappable. Critical information such as promo codes or offer deadlines should never live inside the image file. If your deadline is only readable when the image loads, your fallback has already failed.
Who This Checklist Is For: Roles That Can't Afford a Cropped Header on Send Day
Three distinct roles reach for a crop checklist, and each arrives with a different failure already in progress.
In-house email designers at mid-size brands You are producing headers inside a design system that was built for desktop and never fully stress-tested on mobile. Your failure mode is dimensional drift: the master template specifies 600×200px, but a campaign-specific hero gets exported at 1200×400px without the corresponding `max-width: 600px` constraint in the HTML, so Gmail Android renders it oversized and clips the right edge — taking the product name with it. Image assets should be designed at 1,200px wide and displayed at 600px to render at 2× on retina screens, but that retina export rule applies to the asset, not the container. Conflating the two is the specific error this checklist helps you catch before it ships.
Freelance graphic designers producing Mailchimp campaigns for clients Your client hands you a brand kit and asks for a header. You produce a beautiful 800px-wide banner because it looks right in Figma. Going beyond 700px width increases the risk of horizontal scrolling in older Outlook versions and on smaller mobile screens, and Mailchimp's template container will not save you if the image itself is oversized. Your failure mode is format mismatch: you deliver the right visual but the wrong spec, and the client's first send crops the logo on every Android device. This checklist gives you a client-ready pre-delivery verification step you can run and document.
Small business owners building their own headers You are working inside a drag-and-drop builder and uploading a header image you created in Canva or a similar tool. Your failure mode is above-the-fold content loss: you placed the promotional offer text near the bottom of the image because it looked balanced on your laptop, but critical content should be placed within the top 300–500px of vertical space to remain visible before scrolling — and on a 390px iPhone viewport, your offer disappears entirely. Critical information such as promo codes or offer deadlines should not be placed inside image files at all; HTML text below the image is the safer vehicle. This checklist tells you that before you hit send, not after you check your open reports.
If you recognize your failure mode in any of these three descriptions, the checklist items that follow are written for your specific workflow, not a generalized best-practice audience.
Email Header Dimensions FAQ: Crop, Safe Zones, Retina, and Dark Mode Answered
What is the recommended height for a responsive email header? 150–200px tall at 600px wide covers most email types. Brand-led or visual campaigns can extend to 250px. Beyond 200px, the header consumes a disproportionate share of the mobile viewport before the recipient sees any body content. If your header currently sits at 300px or taller, that is the first dimension to reduce before investigating crop issues. See checklist step 2.
How do I prevent text from being cropped in a mobile email header? The crop is almost always a safe-zone placement problem, not a scaling bug. Keep all text and logos within a centered 440px-wide zone on a 600px canvas. At 320px mobile, that zone scales to approximately 234px — narrow, but enough for a short tagline and logo if type sizes are 18px or larger. Text smaller than 14px in an image file becomes illegible at 320px regardless of placement. See checklist step 4.
What media query breakpoint should I use for a responsive email header? Target `max-width: 600px` as your primary breakpoint. At this breakpoint, switch the header image to `width: 100%` so it scales fluidly down to 320px without overflow or horizontal scrolling. Mobile portrait is 320px; 480px is the upper mobile bound but forces landscape orientation. A single breakpoint at 600px handles both cases if the image is set to fluid scaling.
How does dark mode in Apple Mail and Gmail affect header safe zones? Dark mode introduces a second layer of risk beyond dimensions. Apple Mail can invert the entire image or selectively recolor detected background regions. Gmail on Android applies a dark background to the email container but generally does not invert images. The practical result: a header image with white text on a dark background may render as dark text on a newly light background in Apple Mail dark mode, making the text invisible. The safest mitigation is to avoid embedding critical text inside the image file and instead use HTML text with explicit `color` values and a `prefers-color-scheme` media query override. If text must live inside the image, test the header in Apple Mail dark mode specifically before send. See checklist step 9.
What is the correct export size for a retina-sharp email header? Export the image at 1,200px wide and constrain the displayed width to 600px using `max-width: 600px; width: 100%`. This delivers a 2× pixel density on retina screens without widening the container. The file size penalty of doubling the export resolution is real — keep the compressed output under 200KB by adjusting JPEG quality rather than reducing export dimensions. See checklist step 3.
Start With a Header That's Already Sized Right
Most mobile crop failures are not discovered during design — they surface after a test send, when someone opens the email on an iPhone and the logo is half-visible or the headline is sliced at the fold. At that point, the fix requires re-exporting the asset, updating the HTML, re-testing across clients, and delaying the send. The entire retrofit loop exists because the header was not built to the correct dimensions and safe-zone constraints from the first artboard.
The checklist in this guide gives you the numbers to prevent that: a 600 px container, a 1,200 px retina export displayed at max-width, header height capped at 150–200 px, critical text and logos kept inside the center 400 px horizontal band and the upper 80% of the vertical frame, background-color fallback set on every image cell, and alt text written as a compressed version of the headline rather than a file description. Run those checks before the asset leaves the design stage and the crop problem does not reach production.
If your team uses generative tools to produce header art — a workflow that has introduced new focal-point unpredictability as AI-generated compositions place subjects and text anchors in unexpected positions — the safe-zone discipline described here becomes more important, not less. An AI-generated hero image that looks balanced at full resolution may place the subject's face or the offer text outside the safe zone when the email client applies its height constraint. The checklist items covering vertical crop boundaries apply directly to that scenario.
Veeso AI can generate editable email header graphics pre-sized to the 1,200 px export width and configured with the safe-zone proportions covered in this guide, which removes the step of manually resizing and repositioning a generated asset before it is production-ready. That is a starting-point convenience, not a substitute for running the pre-send checklist — the verification steps for fallback behavior, alt text, and client-specific rendering still require a human check against a live preview.
Save or bookmark the dimension table and the fallback specs above. The most reliable way to protect a send is a checklist your team runs every time, not a set of numbers someone remembers from the last campaign.
Frequently asked questions
What are the recommended email header image dimensions?
For most email types, design your header image at 600px wide × 150–200px tall; brand-led or visual campaigns can push height up to 250px. Keep the file under 200KB—ideally under 100KB—so it loads quickly on mobile connections. Because many clients scale images down on smaller screens, make sure any text or logo in the header remains legible at reduced sizes. Source: warmy.io
How wide should an email template be so it doesn't break on mobile?
Set your template container to 600px wide. This has been the industry standard for over a decade and renders cleanly in Gmail, Outlook, Yahoo, Apple Mail, and on mobile devices without triggering horizontal scrolling. Going beyond 700px raises the risk of horizontal scrolling in older Outlook versions and on smaller phone screens. For mobile portrait specifically, your layout should reflow to 320px. Source: warmy.io and tabular.email
What is the safe height range for an email header, including the logo and nav bar?
Keep your header height between 70–150px ideally, with a hard maximum of 200px when a navigation bar is included. Taller headers push your key message below the fold, reducing the chance recipients see your offer before scrolling. Critical content should sit within the top 300–500px of vertical space so it is visible without any scrolling at all. Sources: selzy.com and tabular.email
How do I make sure my email header looks sharp on retina and high-DPI screens?
Design your header image asset at 1,200px wide, then set its displayed width to 600px in the email code. This 2× approach delivers crisp rendering on retina screens without changing your template container width. Apply the same rule to any banner or hero image. Note that this scaling applies to image assets only—your template container should remain at 600–640px. Source: tabular.email
What file format should I use for an email header—JPEG or PNG?
Use JPEG for photographic headers where rich color gradients matter most, because it compresses well and keeps file size low. Choose PNG when your header contains a logo, text overlay, or transparent background element, since PNG preserves sharp edges and supports transparency. Either way, target a file size under 200KB—ideally under 100KB—to protect load times on mobile. Always verify format support with your specific email service provider. Source: warmy.io
What happens if images are blocked—will my email header still communicate anything?
When images are blocked—which Outlook does by default—your header becomes invisible unless you add descriptive alt text. Meaningful alt text ensures the header's message still reaches the reader as plain text. It also signals to spam filters that the email is properly built. For the same reason, never embed critical information like promo codes or deadlines inside an image; use live HTML text so that content is always visible. Source: warmy.io
What are the right dimensions for an email banner or hero image?
Standard inline banners work well at 600px wide × 150–200px tall. Full-width promotional banners can reach up to 300px tall. The absolute maximum canvas size is 700px wide × 1,730px tall, but most hero images stay well below that. Match the banner width to your template width so no cropping occurs. Because mobile clients often scale images down, design banner text and CTAs to remain readable at smaller sizes. Source: warmy.io and tabular.email
How can I create correctly sized email header visuals before dropping them into my template?
Veeso AI is a visual-content creation tool that lets you generate and resize header images to exact pixel dimensions—such as 1,200px wide for retina export or 600px for standard display—before you bring them into your email builder. It handles image composition and format decisions; it does not send, schedule, or publish emails. Once your header asset meets the dimension and file-size specs above, export it and upload it to your email platform of choice.
What is the mobile crop risk checklist I should run through before sending an email?
Before sending, verify: (1) template reflows to a single column at 320px; (2) header image is 600px wide with height ≤ 200px so it isn't cropped on small screens; (3) image assets are built at 2× resolution for retina; (4) all images have descriptive alt text; (5) critical text like offers or deadlines is live HTML, not embedded in images; (6) CTA buttons are full-width on mobile with at least a 44×44px tap target; (7) preheader text is 50–100 characters. Sources: tabular.email and selzy.com
Does email template width need to change for Outlook users?
Yes—Outlook on Windows uses the Word rendering engine and can behave unpredictably at non-standard widths. If a significant portion of your audience uses Outlook, stay within the 600–640px range rather than experimenting with wider layouts. Templates up to 800px can work for visual newsletters, but only after thorough testing in Outlook, Gmail, Yahoo, Apple Mail, and mobile views. When in doubt, 600px is the safest choice across all clients. Source: tabular.email
