Last updated Jan 9, 2025 — I’ve been a Freelance Dev, and developing banners since 1998. I decided to write this guide to help non-Developers and people new to managing and designing banners understand it all a little better. It is not about design – It is banner development from the Developers perspective, but not for the Developer. In other words, I try to keep code explanations and dev techniques to a minimum, and just stick to subjects that concern the other people in the process.

Sometimes banner Developers may be seen as the people who just say “No” all the time when they are asked to animate something in a certain way, but I think that comes somewhat from a lack of understanding of what banners are capable of – Developers get stuck in between trying not to dumb down the creative vision, but also making sure it will actually work. There are of course some Devs out there who just don’t want to get stuck doing banners, and they become unjustly overly negative. But we’re going to pretend those guys don’t exist for the moment. I actually really like banner development, and by reading below, hopefully you will gain a better understanding of what banners are capable of, and what they are not capable of, so you can take care of the reg flags before the Developer even gets a chance to see it.

Here are the topics I will be covering:

Banner Basics
Specs
Click Tags
Process
PSDs and Design Considerations
Rich Media

I will be updating this guide whenever I think of new items. Comments and critiques welcome. Please don’t take everything said here as stone cold rules, as all projects can have differences – it’s just the experience I have picked up over the years. 


BANNER BASICS
In Canada, banners typically come in 3 main sizes: Big Box (300 pixels across x 250 pixels high), Leaderboards (728×90), and Skyscrapers (160×600). There are quite a few others as well, but these three are the most common, and most banner campaigns will at least include the same creative adjusted to each of these sizes. 300×600 Super Skyscrapers (also called Double Big Boxes and a few other names) are also common, with mobile sizes typically including 300×50, 320×50 and 320×100. IAB specs were updated in 2017 to remove these sizes and use rations instead (such as 1:1, 1:4, etc), but even now these are not yet widely used.

Screencap and logo

There are two basic types of banners: Standard and Rich Media.

Developing a Standard Banner just means that the overall file size needs to be quite small – usually between 50 and 200k depending on the pixel size. This greatly limits what can be done because those are very tiny files.

Rich Media banners used to be used to allow banners to contain things like video and expanding panels. However in the past few years, these sorts of banners not only fell out of favour, but in the case of expandable banners, are no longer allowed. More recently Rich Media banners are used primarily for dynamic content, and, in some cases, used to traffic Standard banners simply because the Media Company requires it (Which has it’s own set of complications).

Banner ads are usually hosted by an Ad Server (such as DoubleClick Studio, DV360, or DCM) which holds the banner on their internal servers and then broadcasts it to the websites that are displaying the ad. Which one being used is determined by the Media Company that did the campaign buy. Sometimes people will claim the host is the Media Company itself, but this is not the case. This usually just means the Media Company is uploading to a server themselves – usually one of Google’s products. It’s important for the PM to find out which server is being used, because the way it needs to be developed will be determined by what company is hosting it. For Standard Banners, if the Media Company is being particularly difficult in communicating this information (In all honesty, probably because they don’t understand the question. This, sadly, is not uncommon), the developer can use DCM specs, as this is by far the most common and works across several other platforms.

It’s also helpful to find out the banner specs (see below) for each individual site the banner will be displayed on. Each site sometimes has slightly different requirements, so the team will need to figure out the LCD (Lowest Common Denominator) in order to determine which specs will be suitable across all sites. Sometimes that is not possible, and multiple banner versions will need to be created. The most common differences are usually length of banner animation allowed, and file size limits.

From a PM and Media Company point of view, a banner consists of two files. A ZIP file containing all the code and images the banner uses, and a backup JPG or GIF file.

The ZIP file is the banner itself, and does not need to be unzipped – it can simply be forwarded along to the Media Company. The file size off the banner is determined by the size of this ZIP file. Some ZIP compression tools are better than others, so it’s important not to un-zip and then re-zip the file when being sent to the Media Company, as that could change the file size and even add invisible files to the ZIP which Media Companies sometimes claim cause an error in their system. DCM, in the early days of HTML5 banners, was notorious for this, and would send stuff back all the time. If this happens, get your developer to check all invisible files from within the ZIP and remove them. One tool in particular which has serious issues with DCM is DropStuff for Mac, which adds invisible files to the zip which are not viewable on a mac, even with invisible files set to visible. If you wish to view the banner from your desktop, you can un-zip the file, and double click the index.html file. This will open the banner in your default browser. Just be sure to keep the original ZIP file to send along to the Media Company.

The backup image is what the user will see if they cannot see the HTML5 banner for some reason. This image was much more important in the Flash banner days when many people did not have Flash installed on their system, or were using mobile devices which did not support Flash at all. With HTML5, it is much less important. Unless the user is using an extremely old browser, or has javascript turned off (which would cause most of the web to not work as well), very very few people will see this image. But it is still a requirement to have. The code to determine which of the banner or the backup image is seen is part of the Ad Server’s system. With most Ad Servers, the Media Company has the ability to adjust which circumstances will switch to the backup image, but this is rarely needed as the default settings are usually fine. Many Media Companies don’t know about this setting, so it’s best to leave it alone unless your banners have a very specific browser target.

Speaking of browser targets, these days HTML5 banners should be programmed to work with the most recent browser versions. Banners shouldn’t be doing anything so complex that older browsers can’t handle it.


SPECS
Before starting to design or develop an ad, both the Designer and Developer need to know what the specs are. The PM should contact the Media Company to get a list of each site’s individual specs, and the name of the Ad Server and its contact person. There are several pieces of information that they need to find out:

SIDE NOTE: Sites occasionally turn a blind eye to Standard Banners that are slightly over spec. I personally like to play it safe and never go over to avoid a possible pushback and therefore delay. But if file size is a big issue and images are looking terrible, the PM may opt to take the chance and give the Dev the go ahead to go over slightly.

File Size – How big is the banner allowed to be? For Standard Banners, this usually means under 150k. Rich Media allows for more technically, but with the way Rich Media servers are used these days to traffic Standard Banners, this needs to be confirmed with your Media Company. The primary item contributing to file size problems are the images in the banner. The Developer can control how big they are, to an extent, by controlling the quality and file type – Better quality means higher file size. There’s a lot more to it than that though – more to come later on this subject.

Dimensions – Usually comes in the previously mentioned Big Box, Leaderboard, or Skyscraper formats, but may also be another size. A common mistake is for Designers to setup Skyscrapers as 120×600 instead of 160×600. 120×600 is another valid size, but not nearly as popular. (IAB specs now use responsive sizes, though not really used yet. More on this later )

Max Animation Time – This is the amount of time the banner is allowed to animate before it must stop completely until the user interacts. This is usually 30 or 15 seconds. This time will include any potential looping, but does not include replay buttons or other user interaction.

Click Tag Code Direction – This is the way that the banner knows what URL the user will click to. I will get into more detail on this later.

Backup Image Size – Max size is usually 40k, but should be confirmed.

Border Colour – Usually Black or White, but more importantly, contrasting between the site and banner. So that can include shades of grey.

Javascript Libraries Policy – This one will not be one that a typical Media Company will usually be able to answer, and in my experience, it’s actually better to just avoid the question. But it’s still important to understand in case the developer wants to know for sure. HTML5 banners use Javascript libraries in order to run (JQuery, Greensock / TweenLite, etc). These are essentially code files that someone else has written in order to make animation a lot easier. Some are bigger than others, but no matter which one the developer prefers, they take up file size. There are two ways of loading these files. The first is have a copy of them in the ZIP file that is sent to the Media Company. The second is to have a call from within your banner that loads it from an external location. Loading it from an external location means that you don’t take up valuable file size from within your ZIP file. If you use common URLs to load these, it also has the advantage of being cached within the users browser. In other words, the more banners that use these public files, the faster it will load for the next banner because the browser will have already loaded it. The problem is that this is a bit of a grey area in terms of file size. Technically you are loading in that file size, so it should be included in your total banner size. But because it’s not part of the ZIP, it’s hard to detect. Usually if you ask Media Companies, they will either not understand the question, or will say that the file size needs to be included. But Media Companies and Ad Servers typically don’t check this. And many Ad Servers, such as DCM, encourage it because of the caching benefit.

Many times, sites will use what is called IAB Specs as its technical development guide. IAB specifications are setup to try to have a uniform standard of tech specs across Canada. The hosting site will usually send a PDF copy of these, or quote them when specs are requested. Be aware that although these specs mention almost everything a developer needs, they do not contain any information about code or Click Tags.

One important note on IAB: The new specs released in 2017 uses new responsive sizes as opposed to the classic 300×250, 160×600, 728×90 sizes, however these are not widely used, and and whenever a media company quotes IAB specs, it can usually be assumed they mean the old IAB specs. Though ask if you want to be safe.

Other times, Media Companies will send along spec sheets which turn out to need a little TLA. They contain outdated Flash specs (A tell-tale sign is if they include a spec called Frame Rate, or Actionscript version, which are both Flash-only specs when it comes to banners, though video does have a Frame Rate spec sometimes), or don’t mention something that you need to know. Best to ask for clarification if you can.

The most important things that need to be known are:
File Size
Max Animation Time
Click Tag Code Direction

All three can be guessed based on IAB or just the most common things done. But best practice is to find out for sure.


CLICK TAGS
As said before, the Click Tag is a piece of code (not to be confused with the URL itself, which can also be referred to as a click tag) which lets the banner know what URL the user will be directed to when clicked. The URL should never be hard coded into the banner itself. For Standard Banners, the Developer does not even need to know what the target URL is – they will use Click Tag code, which the site or Ad Server will then use to dynamically push the URL to the banner. That way, the PM just sends the hosting site the URL, and they then have complete control over where the banner goes without involving a Developer. For Rich Media banners, it’s a bit different if the Dev is setting up the campaign. They still will use Click Tags, but they will need to know the ultimate URL destination to put it into the campaign project control panel.

It’s important for Project Managers to understand what the specific Click Tag code is, because there are several different kinds, and the Developer will need to know which is required. The most common is the following two lines of code, which the developer will know how to use:

var clickTag = “http://www.google.ca”;
window.open(window.clickTag);

The addition of Google.ca in there is just a placeholder, and will be removed by the Ad Server.

SIDE NOTE – Your browser has some temporary memory, called Cache, that stores items you view while browsing so that the next time you visit it, the browser won’t need to download it again – it will already be loaded and ready for viewing. This makes browsing the internet much faster. However, this can be problematic during the dev process because there is no easy way to tell if you are looking at the current version of the banner, or a cached version. If you are viewing a cached version, you will not see changes the Developer has made to the banner. You will need to clear your Cache in order to know for sure. Each browser does this in a different way. Ask your Dev for help if you are having trouble seeing changes made.

There are online tools available if you want to do a quick test to see if the banners are set up correctly (For example, DCM has an online HTML5 validator here. Other servers may have their own services). You simply upload the ZIP file, and it gives you any errors or warnings.


PROCESS
The Development process from a Developer’s viewpoint for banners usually works something like this:

1) First, a brief to the design team, who may or may not want to involve the Developer at this point. Usually it’s not needed for simple Standard Banners, but it’s a good idea for Rich banners. At the very least, the Designer should know what the tech spec limitations are.

2) Creative concepts should be quickly shown to the Developer before shown to client just to make sure there are no reg flags from a production standpoint. The most common issue is that the Developer might see is that the concept will not fit within a 150k ZIP file. The last thing the design team wants is to have to go back to the client to say “Sorry, we can’t do what we promised.”

3) Once concepts are decided on, and layouts are completed and approved, a package of assets is sent to the Developer, and the Designer will give a brief to the Developer. This will include their thoughts on animations and overall flow (A PDF storyboard is excellent if possible). The PM should also let the Developer know the workback schedule. Try to make sure the banner design is final. Adding or removing items after dev has started can sometimes take more time than starting from scratch (although minor text changes are usually not a problem). The most common thing the creative and account team like to add after dev is finished is a replay button. This is usually simple but sometimes a challenge, so best to mention it up front.

4) If the campaign includes multiple banner sizes, the Developer will usually start with developing the Big Box as it is the most common size and gives a good idea as to what file size will be like across other sizes

5) Once the Big Box is approved internally, other sizes are developed. In an ideal world, the client would have also approved the Big Box animation before other sizes are developed to confirm they are happy with the overall flow, style and timing, but that is not always an available option. But it’s awesome when the PM pushes for this.

6) Once English is approved for all sizes, French and any other language adaptations can happen. It is not a good idea to do other languages before English is approved because any changes from the client would then take double the amount of time. French adaptation can either be done by the Designer with new PSDs, or by the Developer directly in the code depending on the Designer’s comfort level with the Developer’s layout skills, and also available time and budget.

7) Once all is approved, the Developer will name the files appropriately, zip it up, and send them to the PM (the PM can rename the ZIP file if they would like, but it’s very important that they do not rename any other files, otherwise the banner will not work. If there is a naming convention, better to get the developer to do this on their end). The PM can then forward this on to the Media Company or websites directly depending on the campaign requirements. In the case of Rich Media, usually the Developer will have already uploaded the files to the Ad Server’s hosting site, so this package will be for internal backup purposes only.


PSD AND DESIGN CONSIDERATIONS
I won’t get into how to design a banner, or the strategy here. I’ll leave that up to the creative experts. However, I do have suggestions on how to setup the PSD file, some things to watch out for when designing that may cause issues later on, and some common things to forget when in the process of designing.

Keep in mind, PSDs are not the only way of providing designs to developers. Figma, XD, and Sketch are also popular and perfectly valid. I find designers who choose them over Photoshop have a good deal of banner layout experience, so I won’t get into how to set up banners in those programs here. One important note: Some designers who don’t have a lot of banner experience sometimes revert to using InDesign to create their banners. This needs to be avoided. InDesign is a print application, and does not allow developers to export images in the way that they need.

File size
A great skill a Designer can learn when designing for banner ads is how to estimate file size.

Images are the main source of Standard Banner file size. Essentially, the larger and more complicated the image, the larger the file size. Each image that needs to be animated will be separated into individual files from the PSD by the Developer, usually as PNG or JPG files. The PNG format is a non-compressed image format so it gives the best image quality. But it is also a very large file. JPGs allow for a lot smaller file sizes, and the quality of the JPG depends on the compression settings. In the example below, the baby on the right has a lot more compression, and is therefore a much smaller image. But obviously the quality is much worse (Just as an FYI, the image on the left would be about 20k, and the image on the right would be about 5k).

Screencap

PNGs, along with higher image quality, also allow for many Alpha (transparency) channels, so things like hair, shadows or smoke (anything that is transparent or only slightly transparent) would be possible to animate across different backgrounds. This is an area which can cause huge file size issues in images. Areas that are only slightly transparent, or items that have complex transparent edges, are especially large. Try to keep them to a minimum.
Screencap
It might be hard to tell which items will need to use Alpha channels and which can just be flattened with the image behind them, but keep your eye out for items that will be moving or have their background change. Especially watch out for moving images that also have shadows, blurs, and complicated small items like hair or sand. The example on the right shows the same image that would have very different file sizes. Assuming that the lime would be moving and the background would be static, the top lime would be the smaller image because it’s on a plain white background and the PNG can just be flattened with the white background behind it. The bottom lime would be much larger because it would have to be close cropped, and the bubbles would need to have many different levels of transparency in order to see the background behind it. For shadows, try to keep them as separate layers so that the Developer has the option to compress them at different levels.

Photographs can be a hard thing to judge how big they are because it greatly depends on the content of the photo. Many different colours and shadows can be much bigger than just flat colours. A photo a brick wall will be much bigger than a photo of a flat white plaster wall.

The question that is always asked – Can we increase the quality of that image? The answer is usually yes, but we need to take quality away from somewhere else.

Keep your eye out for blend modes in PSDs, which do not transfer well to native HTML5. A good test of if it will transfer well would be to select all the layers used to create the image, and make a smart object out of it. If it looks the same, you’re good. If it changes, the Developer will probably have issues and may request a PSD change.

SVG files are an alternative to the more common JPG and PNG formats. While JPGs and PNGs use are bitmap based, SVG is vector, which allows for an object to be scaled without losing image quality. These are more typically used for simple illustrations and logos (Think Nike logo) because complicated vectors can be quite a bit larger than PNGs. It’s a good idea to keep your vector items in the PSD as smart objects, so the Developer has the option of using it as vector, or exporting it as a PNG. Talk to your developer about the advantages and limitations of using an SVG.

Pay attention to any zooming photos. Many times Designers would like to start off on a zoomed piece of an item, such as an eye on a persons face, and then zoom out to reveal the full item. While this is a nice concept, remember that if an image is nice and crisp and clear on the zoomed version of the specific item, the entire image – even the parts of it that are off screen – will need to be high rez as well. This can lead to a very large image.

If possible, keep backgrounds as flat colours, or simple radial or linear gradients that can be re-created in HTML5. This can save 2 or 3k in file size. Remember that the HTML gradient control is simplified compared to Illustrator’s, and does not have any gradient warping capability.

The final thing to keep in mind is to prepare the PSD at retina size. This means for a 300×250 banner, prepare it at 600×500. Essentially double sized. Keep in mind that simply increasing the DPI from 72 to 144 is not the same thing. The actual number of pixels wide/high needs to be doubled, not the number of pixels that display per-inch (DPI – dots per inch). DPI doesn’t matter at all in banner design.

Complex Animations
Keep in mind that anything other than a slide in, zoom in, or fade in, will likely require extra file size or specialized code to work. Discuss things with your developer to see if the animation you have in mind is doable in code.

Fonts
Fonts are a complex subject. Years ago there used to be a debate whether to use live fonts or jsut keep text as images. These days there is simply no debate. Words are images. The only exception is for dynamic banners which load in text from a database on a Rich Media server. A designer might also need fonts if the PSD is not retina and they need to upsize on their end, which cannot be done without the fonts.

Other things to keep in mind
ScreencapLayer comps for each frame are very important. They make sure there is no misunderstanding between Designer and Dev on how the Designer wants each frame to look, and avoid accidentally having unintended layers on or off. Best to name your comps something like: “Frame 1”, “Frame 1 transition”, “Frame 2”, “End Frame”, “Static Backup”, “CTA Rollover”, etc. Delete layer comps not being used, such as old alternate endings to avoid confusion. As an alternative to Layer Comps, Folders that are named like this are also common, but can cause a bit of confusion if there are generic folders, such as “Logo” or “Global Items”, which are intended to be turned on and off depending on the frame. Art Boards are also a popular method and perfectly valid. Make sure each Art Board is properly retina sized.

No matter which way you choose to do it, it’s very helpful to make sure that both ways are not done at the same time. Many times when folders are used, there will still be forgotten Layer Comps that will not show the ad as intended and cause confusion with the Developer on which to use.

Try to keep high rez bitmap smart objects as small as possible. The Developer will not typically need to re-size the items in the layout, unless the item will be zooming (in which case, careful of file size restrictions in the final output), and it can sometimes just cause extra time in downloading the source anytime there is a PSD change. It’s awesome when PSDs for Standard Banners are be between 2 and 20 megs. This is not a rule by any means – just a personal preference.

Make sure the PSD is up-to-date with the copy deck. The Developer will typically copy and paste the text directly from the PSD, or import the text from a PSD layer, so he/she can also get the HEX colour and font size at the same time. Conflicts between the PSD and Deck can cause confusion between what is the most recent version.

Common items forgotten in the design process include:

Button rollover states – Remember that each button can (but does not have to) have a different colour or animation when the user rolls over. A layer comp for each state is helpful.

Borders – Black, white or grey, as long as they contrast with the banner content, and follow whatever the specs are. Colour is sometimes ok as long as it contrasts the site content.

Legal Button – Legal buttons don’t always fit nicely into a design after the fact. Try to find out if it’s needed before design starts, otherwise it might look out of place, or even cover an important piece of the design.

Backup Image This is usually the last item done in the development process. Commonly it is done by either the Developer or Designer saving the last from of the PSD out as a JPG. But this can be problematic if the last frame contains buttons like: Legal (user cannot rollover to see legal in a static image), or Rollover to Expand (User cannot expand in a static image). Or if there is no last frame, such as the case where it’s a Rich Media banner and the user needs to expand to get any information or imagery of the product. A static image of this would not work at all. Make sure that has been thought out. It is a great idea to have a separate layer comp in your PSD to show what you would like the backup image to look like.

Another word on Backup images – They are commonly referred to as Backup GIFs. However. JPEGs are perfectly fine.

Animation on to the Screen – If you have an item that needs to animate on screen and then off, such as something that does a bounce animation on and then flies back to be half off the screen, remember that the Developer will need the entire image, not just the final cropped version of it.

Also, keep in mind when going through your designed frames, that while moving a product image up 5 pixels from frame to frame to accommodate more text looks ok on the storyboard, it looks off when an image slides up only 5 pixels during the animation. Try to keep image placements consistent.


RICH MEDIA
Rich Media servers these days are typically just used for dynamic banners. This is a whole different subject which I’ll get around to writing about at some other point. Keep in mind one important note: If the Media Company is requiring DoubleClick Studio, but giving you Standard Banner specs, that’s a red flag. It’s going to be hard to reconcile file sizes.


Ad Servers
There are many possible Ad Servers out there. Most require the PM or Account person to setup a campaign on the Ad Server’s system before dev starts. How this is done might require some training in their particular method, so speak to your Ad Server rep to find out.

One note is that people commonly confuse DCM and DCS. DCM is DoubleClick Manager, and is used by the Media Company to upload Standard Banners to. DCS is the system in which a developer uploads Rich Media bannrs to. DCM accounts are usually held by the Media Companies. DCS accounts are usually held by the developer or ad agency, and the Media Company is then CC’d when QA is approved, which will then give them access to the traffic info they need.

SUMMARY
Well, that’s all for now. I’ll keep adding items when I think of them, and feedback is encouraged. Im interested to hear anyone else’s experience with banners, and what they had questions about or problems with.

I hope this has helped.