The guide
An email signature should be text a reader can copy, call and hear; a picture can only ever be the extra
Why the block under your name works best as a few lines of real text, what the two-hyphen separator is for, and how to keep its links safe to click.
- 4 lines rule of thumb for a signature in RFC 1855, written in 1995
- 78 characters line length a message should stay within, RFC 5322
- 4.5:1 contrast floor for ordinary text, WCAG 2.2 Level AA
- 8 of 42 listed program and platform pairs that showed no embedded picture
- 75 octets width at which a contact card line is folded, RFC 6350
Read the full guide Fold the guide
The last few lines of a message do a job nothing else in it does. They say who wrote it and how to answer by another route. A set of network manners published in 1995 put it plainly: the signature file “takes the place of your business card”. A business card that some of the room cannot read is a poor card, and that is the risk every picture signature runs.
What breaks when the signature is one picture
The appeal of a picture is control. The designer chooses the typeface, the spacing and the exact shade of the company color, exports one file, and it looks the same wherever it is shown. What that file gives up is everything a reader does with words. A phone number inside a picture cannot be selected or tapped. A name inside a picture cannot be found by searching a mailbox. Nothing in it can be enlarged without blurring.
The accessibility guidelines of the World Wide Web Consortium name the problem directly. Success criterion 1.4.5, at Level AA, reads: “If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text”. The document that explains it says who is served: people who need text in a particular font size, foreground and background color, font family, line spacing or alignment. A picture of words freezes all five at once.
There is a second, older rule underneath. Criterion 1.1.1, at Level A, asks that every piece of non-text content has a text alternative that serves the equivalent purpose, because text can be turned into whatever a person needs: read aloud, shown larger, or sent to a braille display. The HTML Standard is strict about what that alternative is. It is “a replacement for the image, not a description of the image”.
Follow that through. An honest replacement for a signature picture is the name, the role, the organisation, the number, the address and the postal lines, all written out. Once that text exists, the picture has stopped carrying information. It has become decoration sitting beside the real thing.
Then there are readers who never see the picture at all. The HTML Standard allows a program to obtain images on demand rather than at once, and mail programs are commonly reported to hold pictures back until the reader allows them. No figure is given here, because none could be found in a source fit to cite. The safe design does not need one: if nothing depends on the picture, it does not matter how often it fails to appear.
Writing the picture into the message itself does not rescue it. The format for that, the data address, was described in 1998 with the remark that it “is only useful for short values”. Base64 turns every 3 bytes into 4 characters, so a banner of 12,000 bytes becomes 16,000 characters of markup. In one openly licensed set of support data, last tested in February 2020, 31 listed program and platform pairs showed such a picture, 3 showed it partly, and 8 of 42 did not show it. That data is old. Read it as a warning, not as a measurement of today.
Text first, built the old way
So the tool on this page makes the text the signature and treats any picture as an optional extra. The text is written as a small table with every style inline. That choice needs an honest note, because the HTML Standard says “Tables must not be used as layout aids”. Mail is the long-standing exception in practice, since mail programs are commonly reported to drop style sheets. The table is marked with a presentation role, one of the signs the standard itself lists for a layout table. None of this was tested in any mail program.
Color is harder than it looks, because a signature does not own its background. It sits on whatever the reader’s program paints, light or dark. The guidelines ask for a contrast ratio of at least 4.5:1 for ordinary text and 3:1 for large-scale text, which they define as 18 point, or 14 point bold.
Run the arithmetic and a hard limit appears. Against white, a color reaches 4.5:1 only if its relative luminance is about 0.18 or lower. Against a near-black of #121212, it needs about 0.20 or higher. No color sits on both sides of that gap. Ordinary text in one fixed color cannot pass on both backgrounds.
The example that loads with the tool shows the two ways out. Its body text and links carry no color at all, so they take the reader’s own. Only the name is colored, in #c2410c at 19 pixels bold, which counts as large-scale text. That orange measures 5.17:1 on white and 3.61:1 on #121212, above 3:1 on both. Change the name to regular weight and the tool reports a failure, because the threshold rises to 4.5:1.
Width follows the same thinking. The table has a largest width and no fixed one, so on a narrow phone it is as wide as the screen and the words wrap. Three layouts are offered: stacked lines, two columns with a picture cell, and a single line that folds where it must.
Two hyphens and a space
Every message also has a plain-text form, and there the signature has its own punctuation. RFC 3676 records “a long-standing convention in Usenet news which also commonly appears in Internet mail” of using -- “as the separator line between the body and the signature of a message”. It then names the three characters: DASH DASH SP.
The space matters. Software that knows the convention looks for exactly that line, and the same document tells a receiving program to test for a signature line before it tests for a quoted one. Two hyphens alone are just two hyphens. The trailing space is invisible and easy to lose when copying by hand, which is why the tool offers a button.
Line length has its own numbers. The message format standard says each line must be no more than 998 characters and should be no more than 78 characters. RFC 3676 suggests wrapping long paragraphs at 72 or fewer and notes that 66 has been called the most readable. It also says a single word longer than the limit should be sent whole. The tool wraps at 72 and keeps a link address in one piece, since a broken address opens nothing.
How long should the whole thing be? The 1995 guidance again: “If you include a signature keep it short. Rule of thumb is no longer than 4 lines.” Its stated reason, people paying for connectivity by the minute, has mostly gone. The habit has not aged at all. The example signature runs to eleven plain-text lines, and the tool says so without forbidding it.
Links that are safe to click
A signature holds three kinds of link, and each has a standard that says what may go inside it. For telephone numbers, RFC 3966 defines a global number as a plus sign followed by digits and says such numbers “SHOULD be used”. Hyphens, dots and parentheses may be kept as visual separators. Spaces must not. So the number shown as +1 202 555 0142 is linked as tel:+12025550142. A local number needs a context the tool cannot know, so it is written as text and left unlinked.
Mail addresses need more care than they seem to. RFC 6068 lists characters that must be percent-encoded in the address part of a link, among them the percent sign, the slash, the question mark, the number sign, the ampersand, the semicolon and the equals sign. Take the address a?subject=hi&body=x@a.example, which is legal in shape. Written raw into a link, everything after the question mark would be read as a subject and a body. Encoded, it becomes mailto:a%3Fsubject%3Dhi%26body%3Dx@a.example and stays one address.
Web addresses are held to two schemes, http and https. Anything else is refused, and so is an address that carries a user name or password before the host. These are shape rules. They say a string is well formed, never that a number rings or a page exists.
Every value is then escaped for the place it lands. The HTML syntax forbids a literal quotation mark inside a double-quoted attribute and a bare less-than sign in text, so those are written as character references. The preview sits in a sandboxed frame, which the standard describes as content from a unique opaque origin with scripts disabled. It shows one browser’s drawing of the markup and nothing more.
Keeping it short, and what this cannot do
Shortness is easier when the extra facts have somewhere else to live. A contact card file does that job. RFC 6350 gives the format: one property per line, commas, semicolons and backslashes escaped, and long lines folded at 75 octets without splitting a character. A reader who wants the postal address can keep the card. The signature can then stop at a name, a role and two ways to reply.
Copying has a standard as well. The clipboard specification lists plain text and HTML among the types a browser must be able to place on the clipboard, so one press can carry both the markup and its plain companion.
Some things are out of reach. A page in a browser cannot test a mail program, and a mail program may rewrite what is pasted into its signature box. Nobody here can say how a given program recolors a message in dark mode. A confidentiality line is written exactly as typed, with no opinion on whether it has any legal effect. The example person and number are invented, and the example host ends in a top level name that RFC 2606 set aside in 1999 for documentation.
The test of a signature is simple and a little severe. Can a stranger call you, write to you or find your office from it with pictures off, on a dark screen, or by ear? If the answer is yes, a banner underneath is a pleasant flourish. If the answer depends on the banner, it was never a signature.
Sources
Every source consulted for this guide. Links checked October 11, 2026.
- RFC 1855: Netiquette Guidelines Internet Engineering Task Force
- RFC 3676: The Text/Plain Format and DelSp Parameters Internet Engineering Task Force
- RFC 5322: Internet Message Format Internet Engineering Task Force
- RFC 6068: The 'mailto' URI Scheme Internet Engineering Task Force
- RFC 3966: The tel URI for Telephone Numbers Internet Engineering Task Force
- RFC 6350: vCard Format Specification Internet Engineering Task Force
- RFC 2606: Reserved Top Level DNS Names Internet Engineering Task Force
- RFC 2397: The "data" URL scheme Internet Engineering Task Force
- RFC 4648: The Base16, Base32, and Base64 Data Encodings Internet Engineering Task Force
- Web Content Accessibility Guidelines (WCAG) 2.2 World Wide Web Consortium
- Understanding Success Criterion 1.4.5: Images of Text W3C Web Accessibility Initiative
- Understanding Success Criterion 1.1.1: Non-text Content W3C Web Accessibility Initiative
- HTML Standard, 4.8.4 Images WHATWG
- HTML Standard, 4.9 Tabular data WHATWG
- HTML Standard, 13 The HTML syntax WHATWG
- HTML Standard, 4.8.5 The iframe element WHATWG
- Clipboard API and events World Wide Web Consortium
- Can I email: support tables for HTML and CSS in emails Remi Parmentier and contributors, on GitHub
- Can I email feature data: Base 64 image format Remi Parmentier and contributors, on GitHub