Maximum width for HTML emails
You’ve probably noticed that the majority of email newsletters you receive these days are designed with a fixed width as opposed to a fluid layout.
This is because the majority of email clients and web-based email providers don’t use the full width of your screen to display an email message. Whether it’s ads on Gmail, a menu in Hotmail or your Inbox in Outlook, a chunk of screen real estate is often already being used.
Remember, your recipients are busy and impatient, so horizontal scroll bars are even more of a no-no in email than a web page.
Because of this, it is a good idea to keep your emails to a fixed width of no more than 550-600 pixels. This should ensure that in most cases, your subscribers can view your email as you intended.
What about height?
Obviously the height of each email you send will vary depending on the amount of content. At the same time, it’s good to keep in mind that a lot of your recipients may scan your email in a preview pane before they decide to read the entire thing.
The average preview pane is around 300-500 pixels high, so make sure you include any important bits of your email in this area. First impressions count.
Posted in: Tips & Resources
Comments for this entry are closed.
Browse the Blog
- Behind the Scenes (28)
- Interviews & Buzz (132)
- New Features & Updates (229)
- Observations & Answers (210)
- Release Notes (1)
- Tips & Resources (478)
Explore the Email Gallery
- All designs
- One column (368)
- Two column (221)
- Three column (33)
- Announcement (126)
- Newsletter (445)
- Invitation (37)
@Wraggamuffins Yes, as long as the email address stays the same - that’s the identifying data
Follow us on Twitter-
Not just good looks
Track every aspect of your campaigns like opens, clicks, forwards, sales and more.
-
CSS support in email
Designing for email can be tricky. Save your sanity with our complete CSS guide.
-
Free templates
Over 30 professionally designed email templates tested in all major email clients.
About • Our Book • Contact • API • Anti-spam Policy • Terms of Use • Privacy Policy
Proud founders of the Email Standards Project and supporters of the design community.
24 Comments
Damien Buckley
April 12, 2005 9:33pm
Sounds reasonable and should help with making emails more easily printable too. I’ve noticed Macromedia & Apple stick to 650-670px wide or less. What’s everyone else think?
Jamison Hiner
April 28, 2005 12:50am
I keep mine between 600 - 650 wide, As far as length goes I leave that up to the amount of content I have. I figure most people are use to scrolling by now.
Miranda Ball
April 28, 2005 11:41am
I find that when I create a fixed width email end-users ask for expandable, and vice versa! Catch 22! :0
Jonas
April 28, 2005 6:21pm
I never use more space than 650 pixels. It seems to work just fine. The lenght can vary from 400 pixels to 2000 pixels. It really depends on the content. It more important to have interesting content than setting a max lenght.
David Greiner
May 2, 2005 1:43pm
Jonas,
I completely agree with your comment about the height of email. I probably didn’t explain my point clearly, but I still think it’s a good idea to ensure the most important point/image/story of your newsletter should appear at the top of the email to increase the chances of it being read when in the preview pane.
As you say, good content is important and keeping it at or near the top ensures your readers notice it.
David Crowther
May 14, 2005 1:28am
What about using a Table and setting its width to 100%? Would this allow a fluid layout without invoking any horizontal scroll bars?
David Greiner
May 15, 2005 10:40am
David,
Sure would. As long as the minimum width of the fluid layout was still less than 550-600 pixels, you could assume a fluid layout will work fine and avoid horizontal scroll bars.
Nathan Rosenberg
August 18, 2006 10:08am
I’m confused. The new templates just released and the CSS templates are both 700px wide. Why is that if 550-600px is preferable?
Dave Greiner
August 18, 2006 2:37pm
Nathan, you should be safe enough with either width, but I certainly wouldn’t go over that and you should consider that as a maximum. This figure was never set in stone and really depends on what email environment’s your recipient’s might be using.
At the same time, resolutions are slowly getting bigger and don’t forget this recommendation is more than a year old.
Amber
September 20, 2006 12:53am
I did some research comparing Outlook, Hotmail, and Gmail (interface similar to Yahoo/most web-based email clients provided by ISPs) and how much of a message was visible at 800x600 and 1024x768.
What I decided on is a 550 width b/c that is visible in all scenarios. As for height, you have between 250-370pixels before the fold, so I try and get as much imporant/compelling info in that space so readers will be interested in scrolling down.
Hope this is helpful for some of you.
Michael Philip
April 24, 2007 11:28pm
Got a little question for all you gurus:
Is it possible to use DHTML in an e-mail newsletter (for example having expanding content?)
Dave Greiner
April 24, 2007 11:43pm
Sorry Michael, but pretty much every email client out there blocks JavaScript by default. Because of this, scripting just isn’t an option in email.
kiat
November 5, 2007 9:27pm
i’ll stick with 650 for both adequate width and sufficient coverage exposure both in 2007’s resolution trend, webmail/desktop email clients viewable area.
:)
Erudit
December 4, 2007 6:04am
Who tried email-client Foxmail?
... very convenient html editor
Actualist
January 6, 2008 2:22am
>no more than 550-600 pixels
not agree
presently, the monitors allow and more
JohnBH
January 15, 2008 10:10am
Why not go almost to 800 px wide (like 790) since most PC’s are native 1024 x 768 and the newer ones are all 16 x 9 wdiescreens and have at least 1024 for width? Is the huge unused border for readability (white space?) How many 800 x 600 displays are still out there among your email targets, anyway?
JAaronAnderson.com
January 26, 2008 3:43am
I understand default preview is 530px for AOL & the average email viewer can see 60 characters in his subject line
Raye
March 27, 2008 5:40pm
if you look at outlook 2003, the preview is in columns. so the preview email column is actually only half the screen depending on how the user sets their outlook. so small is still good. and all the users who use their mobiles to check emails.
Bridget
March 29, 2008 4:21am
Any ideas on how to print a very long email - many of my clients want to keep it to one page - even though they have a lot of content.
Would scaling the images and typing a @media = print style to the header of the email be the best - or…?
Rules
June 26, 2008 7:09pm
Nathan, you should be safe enough with either width, but I certainly wouldn’t go over that and you should consider that as a maximum. This figure was never set in stone and really depends on what email environment’s your recipient’s might be using.
zakłady bukmacherskie
October 2, 2008 7:29pm
I decided on is a 550 width b/c that is visible in all scenarios. As for height, you have between 250-370pixels before the fold, so I try and get as much imporant/compelling info in that space so readers will be interested in scrolling down.
free web directory
October 2, 2008 7:32pm
At the same time, it’s good to keep in mind that a lot of your recipients may scan your email in a preview pane before they decide to read the entire thing.
JayZee
December 3, 2008 3:31pm
I have a follow-up question. Though it’s not necessarily the best idea in the world, I have a client who wants to create a horizontally scrolling email. It’s basically 6 float:left tables of around 700px wide enclosed in a div that defines the overall width.
As usual, it’s fine in everything except Outlook 2007.
Does anyone know if Outlook 2007 imposes a maximum total width on HTML emails? Very wide content seems to get cropped at around 2200px.
Lawrence Brown
December 18, 2008 5:59am
@JayZee Try looking at http://lecool.com - once you sign up they will send you a email that is formated for horizontal scrolling - mine always looks fine in Gmail and Apple mail - you could check out there code and see if anything unique is going on.