Email signature generator — table layout, inline styles, and a plain-text version

Because classic Outlook for Windows does not render mail with a browser engine. From Outlook 2007 onwards, Microsoft switched the rendering of received mail to the layout engine used by Word, and it is still what the classic desktop client uses. That engine has no support for flexbox or grid, ignores max-width, and handles floats and margins differently from every browser you would test in. So a two-column signature built with flex arrives as two stacked blocks. This page emits a layout table instead, which is the one multi-column construction that behaves the same in Word’s engine, in a browser and on a phone. Note that this is specific to the classic Windows client — the newer Outlook for Windows and Outlook on the web use a web renderer, and Outlook for Mac has always used WebKit.

For a page, yes, they are outdated, and using one for layout is a genuine accessibility problem. For a signature the trade is different: the layout has to survive a rendering engine from a word processor, and a table is what survives it. The accessibility half is handled by writing role="presentation" on the table, which tells a screen reader this is not tabular data and stops it announcing your name and phone number as a two-column grid with headers. That attribute is in the output above — look for it.

A signature never gets a document of its own. It is pasted into the body of a message, so there is no <head> for a <style> block to sit in, and in Gmail’s settings the field you paste into is a rich-text editor that keeps style attributes on elements and does not keep a <style> element. Anything that depends on a selector — a class, a descendant rule, a media query — is therefore gambling. Inline styles have no selector to lose. This is narrower than the claim you will see elsewhere that Gmail strips all <style> blocks: Gmail has rendered <style> in the head of a received message since 2016. It is the signature specifically that has nowhere to put one.

Because an uploaded file would have to be embedded as a data URI — the whole image written into the src attribute as text — and Gmail does not display data-URI images. Several other clients strip them too. The signature would look perfect in your own preview and arrive with a broken image for a large share of your readers, which is the worst kind of failure: invisible to the person who made it. The image needs its own https:// address that any mail client can fetch. Put the file wherever your website lives, or on any host that serves it publicly, and paste that URL. If you have no such host, a text-only signature is genuinely the better answer.

Three usual causes. First, no width: the width slider writes both a CSS width and an HTML width attribute, because Word’s engine ignores max-width and honours the attribute. Second, a relative path such as /logo.png — that resolves against the page it sits on, and once the message is in someone else’s inbox there is no such page. Third, images off: many clients block remote images until the reader clicks to show them, which is why the alt-text field matters. Alt text is what most recipients see the first time your message arrives.

In Gmail, Settings → See all settings → General → Signature, and use “Copy as rendered”. In Outlook on the web, Settings → Mail → Compose and reply. In classic Outlook for Windows, the signature editor is a Word editing surface, so a rendered paste works there too. Apple Mail is the awkward one: its signature box strips a lot on paste, and the usual route is to paste in, tick and untick “Always match my default message font”, or to edit the saved signature file directly. Some clients accept an HTML file, and that is what “Download .html” is for.

Two hyphens followed by a single space, on a line of its own. RFC 3676 names it as the signature separator, and clients that implement it will collapse or hide everything below it when quoting your message in a reply. That is the difference between a ten-message thread carrying one signature and one carrying ten. The trailing space is part of it and is easy to lose when retyping by hand, which is why it is generated here rather than left to you.

Because an icon is an image, and every image in a signature has the same two problems as the logo: it needs a public URL, and it is invisible to a reader who has images blocked. A row of six icons with images off is a row of six empty boxes or six alt texts, neither of which is better than the word “LinkedIn” as a link. Text links also survive forwarding, quoting and plain-text conversion. If you want icons, host them yourself and add them afterwards — but check what they look like with images turned off before you commit.

Partly, and this is worth being honest about rather than promising. Several clients recolour message content when the reader is in dark mode, and they do it in different ways — some invert light backgrounds, some leave the message alone. A signature that sets dark text and never sets a background gives those clients the least to fight over, which is what this page generates. The one thing to avoid is a logo saved as a dark PNG on a transparent background: it disappears on a dark background and there is nothing in the HTML that can rescue it. A logo with its own solid background, or a light version, is the fix.

No. The signature is built in the JavaScript this page already loaded, and nothing is written to localStorage, so closing the tab leaves nothing behind — including on a shared machine, which matters when the fields are your own phone number and office address. The one network request involved is your browser loading the logo image from the address you gave it, which happens on your machine, direct to that host, exactly as a mail client would. Leave the logo field empty and the page makes no request at all.