Web Banner Maker

A poster designer is given a sheet of paper and fills it. A banner designer is given a message and a list of rectangles, and the rectangles disagree with one another. One is a strip eight times wider than it is tall. One is a tower nearly four times taller than it is wide. One is close to square. The same five words, the same mark and the same small button have to sit comfortably in all of them.

The natural first instinct is to design one and resize it. That instinct is wrong, and the arithmetic shows why in a single line. The rest of the craft follows from accepting that a banner is a set of rules that produces a picture for each frame, not a picture.

How the rectangles multiplied

Wikipedia’s account of the web banner dates the first one sold by HotWired to October 27, 1994. The early web had no agreed sizes at all. The same article reports that before any trade body standardised them, banner ads appeared in over 250 different sizes, which meant that every site an advertiser dealt with could ask for its own artwork.

Standard lists eventually cut that number down, and the article reproduces one such list. This page does not quote any of them. The published guidelines of the trade body concerned sit on a site whose terms restrict its materials to personal use, so the sizes offered in the tool above are simply ones in common use: 300 by 250, 728 by 90, 160 by 600, 320 by 50, 300 by 600 and 970 by 250. Treat them as a starting set. Whoever runs your banner decides which sizes they accept, and their list is the one that counts.

Even a short list spans a startling range of shapes. Among those six, width divided by height runs from about 0.27 to about 8.1. No single composition is comfortable across a thirtyfold change in proportion.

Why scaling fails

Take a design made at 300 by 250 and ask it to fill a 160 by 600 tower. To cover the tower’s height the picture must grow by 600 divided by 250, which is 2.4 times. But 300 pixels of width enlarged 2.4 times is 720 pixels, and the tower is 160 wide. More than three quarters of the design now hangs outside the frame. A headline that was 270 pixels wide has become 648 pixels wide, and the reader sees a slice out of the middle of it.

Scale by the width instead and the opposite failure appears. The factor is 160 divided by 300, a little over half, so the design shrinks to 160 by 133 and sits in a tower with 467 empty pixels beneath it. A 31 pixel headline has become a 17 pixel one. Neither answer is a banner.

Photographs have a well understood answer to this problem. The CSS Images specification defines a cover fit: the picture keeps its own proportions and is scaled until it fills the whole box, with the overflow cut away. A background can be treated that way because losing its edges costs little, as long as the part that matters stays in view. That is what a focal point is for. The tool slides the crop so the chosen point stays as close to the middle of the frame as the picture’s edges allow.

A photograph from a phone also has to be turned the right way up first. Browsers decode a picture according to the orientation recorded inside the file, and the tool relies on that before it crops anything.

Words cannot be cropped. They have to be laid out again.

Anchors, regions and margins

The method that works is to stop thinking in coordinates and think in relationships. The mark belongs at the start. The button belongs at the end. The headline sits against the supporting line. Each of those statements is true in a strip, a block and a tower, even though the pixel positions have nothing in common.

In the tool each layer owns a region, a share of the frame along its main direction, and is then placed inside that region by an anchor. An anchor is a pair of numbers between zero and one. Zero means the near edge, one the far edge, a half the centre, and anything else a proportional offset. A layer that is no larger than its region cannot leave it, whatever the anchor says. Wide frames set the regions side by side; square and tall frames stack them. When a layer is hidden, its share is divided among the rest.

All of this happens inside a safe box. The margin is a percentage of the frame’s short side, because the short side is the one that runs out first. At the default six percent a 300 by 250 block keeps 15 pixels clear all round, while a 728 by 90 strip keeps 5. A fixed margin of 15 pixels would eat a third of that strip’s height.

A thin border is the other edge worth thinking about. A pale banner placed on a pale page has no visible boundary, and a reader cannot tell where the page stops and the message begins. One pixel of a darker line fixes that. This is advice rather than a rule, and the tool flags it only when the rim of the banner is actually light.

Small type, real pixels

Text is where small frames are unforgiving. The tool sizes type from the square root of the frame’s area, so a headline that gets 31 pixels in the 300 by 250 block starts at 15 in the 320 by 50 strip. From there the fitting rule is fixed and stated: shrink one pixel at a time to a minimum you choose, wrapping between words; if that fails, break an over-long word; if that fails, cut the text and end it with an ellipsis.

The cut is never made through the middle of a character. Unicode’s text segmentation annex describes grapheme clusters as user-perceived characters, and a letter with a combining accent, or an emoji built from several code points, is one cluster. Browsers expose that segmentation through Intl.Segmenter, and the fitting rule uses it.

A banner is shown at one picture pixel per page pixel, so nine pixel text in the file is nine pixel text on the screen. The tool’s legible floor, 11 pixels by default, is its own judgement and can be moved. When a line falls under it the honest fix is usually to drop that line from the small size, which the per-size switches allow.

Contrast, unlike the floor, has a published definition. The W3C guidelines compute a relative luminance for each colour from its red, green and blue values, weighted 0.2126, 0.7152 and 0.0722, and define the contrast ratio as the lighter luminance plus 0.05 divided by the darker plus 0.05. The scale runs from 1:1 to 21:1. The guidelines ask for at least 4.5:1 for text and for images of text, and 3:1 for large text, meaning at least 18 point or 14 point bold.

The same guidance says plainly that the requirement covers text that has been rendered into pixels and stored in an image format. A banner is exactly that. White on a mid grey of #777777 comes to 4.48:1 and misses; one step darker, #767676, reaches 4.54:1 and passes. Over a photograph there is no single background colour, so the tool reads the pixels behind each line and reports the lowest ratio it finds.

Weight is a budget, not a guess

A banner is a guest on someone else’s page, and it arrives as bytes. The 2024 Web Almanac puts the median page at 2,652 KB on desktop and 2,311 KB on mobile in October 2024, and notes that the median desktop page loads 18 images. Its authors call page weight an accessibility issue, because heavy pages fall hardest on people without fast connections, generous data allowances or expensive devices.

Google’s performance guidance defines a performance budget as a set of limits on the things that affect speed, such as the total size of a page. A banner needs the same discipline in miniature: a number of kilobytes, decided before export. This page states nobody’s limit as a rule, since any such figure belongs to whoever runs the banner. You type your own.

Format matters. PNG is lossless by specification, so flat colour and sharp type survive exactly but photographs cost a great deal. JPEG, in the simple JFIF wrapper the Library of Congress describes, trades detail for size. Google reports that lossy WebP files are 25 to 34 percent smaller than comparable JPEGs. Browsers can write these from a canvas, and they fall back to PNG when asked for a type they do not support, so the tool tests for WebP before offering it.

For the lossy formats the tool searches. It encodes at high quality; if the file is within your budget it stops. Otherwise it tries the lowest quality it allows, then bisects, keeping the best file it has actually measured at or under the limit. If even the lowest quality is too heavy it says so and marks the file as over budget. It never estimates.

The finished set leaves as one ZIP archive, a format the Library of Congress describes as designed for cross-platform exchange of a set of related files. A plain text list inside it records each file’s size and weight.

A worked example

Open the tool as it loads. Six sizes are on the board, all carrying the headline “Fresh bread, every morning”. Select 300 by 250 and read the panel for that size: a square frame, stacked, with a margin of 15 pixels. Then select 728 by 90: a wide frame, side by side, with a margin of 5 pixels. The words are the same and nothing has been stretched.

Now select 320 by 50. Its supporting line is hidden, a per-size choice the example makes because the strip is only 50 pixels tall. Switch it back on and watch what the rule does with three layers of text in that height.

What the picture cannot say

An image of text is silent to a screen reader. The W3C guidelines prefer real text wherever the technology can produce the look, and both the W3C’s images tutorial and the HTML Standard say that when a picture consists of text, its alternative should be that same text. Write the alt text once, and place it with every copy of the banner.

The method has limits worth stating. It checks legibility by size and contrast, not by reading the words. It measures bytes, not loading time on any real network. It knows nothing about the page your banner will land on, and it cannot tell you whether anyone will act on it. What it can do is make sure that the message a person sees in the tower is the same message, whole, that they would have seen in the strip.