Email Signature Builder and Checker

An email signature is the smallest document most people ever publish, and the one they publish most often. It rides along under every message, read by people who did not ask for it, on screens and in programs the sender will never see.

That is why the best signature is not the prettiest one. It is the one that still says who you are and how to reach you when the images are blocked, the colours are flipped and half of the markup has been thrown away.

The habit is older than formatted mail. Signature blocks began as a few lines of plain text at the foot of mail and news posts, written in monospaced ASCII because they predate MIME and HTML in email. Businesses later turned them into something closer to a printed business card, with logos and sometimes an attached contact file, and some countries require company details such as the registered name and number in business mail.

What belongs in a signature

A useful signature answers three questions: who wrote this, what is their role, and how can I reach them. A name, a title and company, one email address, one phone number and one or two web addresses cover it. Legal lines belong there only where the law asks for them. Long disclaimers are a different matter: their legal weight is unclear and they are routinely mocked.

What does not belong is just as clear once you know how mail is read. One mail program’s handbook says plainly that it does not support JavaScript at all, so a script in a signature is dead weight at best. A form is clutter. Frames and outside style sheets depend on someone else’s server, and styles in the head of a message are often stripped entirely, which is why inline style attributes became the working standard for formatted mail, inefficient as they are. A signature built from a table, inline styles and real text survives the trip; one built from a style sheet in the head does not.

Short also matters for a plain reason. Your signature repeats in every reply, so a block of twelve lines becomes a wall of twelve lines times the length of the thread. The separator line helps here. By a long Usenet convention, also used in mail, the signature starts after a line holding exactly two hyphens and a space, written -- . RFC 3676 says that line is sent as it is, and many news and mail readers use it to leave the signature out when they quote a reply.

Pictures that never arrive

Here is the uncomfortable part. A picture in a signature is usually not in the message at all. It is an address on a server, and showing it means the reader’s program has to ask that server for it. That request tells the server the message was opened, and often more. The trick has a name, the web beacon or spy pixel: an image as small as one pixel, transparent or the colour of the background, whose only job is to report the open. Because of that, the usual defence is not to download remote images automatically, at the cost of messages that look broken until the reader allows them.

Mail programs take that defence seriously. The help pages of one widely used open-source program state that it blocks remote content, and does not download it, by default, so the sender learns nothing about the reader. The handbook of another recommends leaving the loading of outside references off and, by default, shows HTML messages as plain text. A logo that lives on a web server will therefore often appear as an empty box or not at all.

So the logo is optional and the text is not. Give every image alt text, so a blocked picture still says something, and a width and height, so the layout does not jump or show a huge image when it finally loads. Never put the phone number or the address only inside a picture. And treat any image of one or two pixels in an old signature as what it almost certainly is: a tracker that has no business reporting on your correspondents.

Links people can trust

Formatted mail lets any text stand for any address, and phishing depends on exactly that. A link that shows www.example.org but leads somewhere else is a classic. The fix is simple to state: when visible text looks like an address, a phone number or a web host, it must agree with where the link really goes. Text such as “my profile” makes no promise and needs no comparison, but “sample.person@example.org” pointing at a web page breaks one.

The schemes a signature needs are few. Web links should use https. Email links use mailto, whose rules in RFC 6068 say that characters such as ”&”, ”;”, ”?” and ”%” inside an address must be percent-encoded. Phone links use tel, and RFC 3966 makes a number global only when it starts with ”+” and the country code, with hyphens, dots or brackets allowed as separators. A number without the ”+” needs a context the signature cannot supply, so it is better shown as plain text. Anything else, above all javascript: and data: links, has no place there.

Checking an old signature for all this has to be done carefully. Parsed as text/html by the browser’s DOMParser, a pasted signature becomes a separate document in which scripts are marked non-executable and event handlers do not run. The same page warns that such a document can still download resources named by images and frames, so a careful checker never shows the parsed copy itself. It rebuilds the signature through an allowlist of elements, attributes and style properties, removing script elements and handlers such as onclick, the same principle behind the browser’s own sanitizer interface, and it names every removal so nothing disappears silently.

Contrast in two lights

Colour is where good intentions fail quietly. WCAG 2.2 defines the relative luminance of an sRGB colour, linearising each channel and weighting green most, and the contrast ratio between two colours as the lighter luminance plus 0.05 over the darker plus 0.05. The range runs from 1:1 to 21:1. Normal text needs at least 4.5:1, and large text needs 3:1, where large means 18 point or 14 point bold. With 96 CSS pixels and 72 points to the inch, that is 24 pixels, or about 18.67 pixels in bold.

A worked example shows the trap. The sample old signature this tool opens on first load sets its body text to #999999, a fashionable light grey. On white that gives a ratio of 2.84:1, far below 4.5. Its name is set in a deep navy, #1a2b4c, which reaches 14.05:1 on white and looks impeccable.

Now picture a dark mail view with a background of #1f1f1f, and the same navy falls to 1.17:1. The name is effectively invisible, and nothing in the original design warned about it.

Can one colour serve both? The arithmetic says not quite. A text colour does best on both backgrounds when its two ratios are equal, which happens when its luminance plus 0.05 is the geometric mean of the two backgrounds’ values. For #ffffff and #1f1f1f that best case is about 4.06:1, short of 4.5.

Even against pure black the best possible is about 4.58:1, barely over. A fixed text colour that passes everywhere does not exist.

That leads to the least glamorous advice in this essay: leave the body text colour unset. Text with no colour of its own takes the reader’s default, which their program can adapt to its dark view. Some programs also rewrite colours you did set when they switch to dark; others leave them alone. Keep colour for links and a thin accent rule, check those against both panels, and remember that a link should be recognisable by an underline, not by colour alone.

A plain-text twin and a contact card

Formatted mail often travels with a plain-text twin, generated so that text-only readers see something sensible. Your signature deserves an exact plain version, not an afterthought. RFC 5322 asks for lines of no more than 78 characters, and RFC 3676 suggests wrapping longer paragraphs at 72 or fewer, adding that 66 has been called the most readable. Link text that does not already show its target should be followed by the target, because a plain reader cannot hover.

The most useful thing a signature can offer is often not in the signature at all. A vCard file lets the recipient save your details in one step instead of copying them field by field. Version 4.0, RFC 6350, is stricter than 3.0 in useful ways. It is always UTF-8. The VERSION line must come straight after BEGIN, and FN, the formatted name, must be present. Commas, semicolons, backslashes and line breaks inside values are escaped with a backslash.

Line folding hides the subtle bug. A vCard 4.0 line should be folded at 75 octets, continued on the next line after a single space, and a multi-octet character must stay in one piece. The older 3.0 profile spoke of 75 characters, and the difference bites the moment a name leaves ASCII. A Greek letter takes two octets in UTF-8 and a katakana sign takes three, so a full line holds only about 25 katakana. In a test of 1,000 generated contacts with multibyte names, folding at 75 characters instead of 75 octets produced lines up to 173 octets long; folding by octets kept every line within 75 and every character whole.

All of this can be checked on your own device, and none of it needs a network. That is also the limit. An offline checker reads syntax: it cannot tell whether a link is alive, whether the logo exists on its server, or how one particular mail program will draw the result. It cannot predict which dark views rewrite colours. It reads email addresses only in their plain dot-atom form, so a quoted local part is reported rather than trusted.

What it can do is make the failure cases visible before anyone else sees them. Open the old signature, see what was removed and why, look at it in a light and a dark panel with the images replaced by labelled boxes, read its plain-text twin, and save a contact card that any address book can import. A signature that passes those checks will look plainer than a designer’s mock-up. It will also be read, every time, by everyone it reaches.