Puttin’ a (Link/Meta) Bow on It

Beyond rendering directly in browsers themselves, web pages also exist in the contexts of search engines, social media, messaging, and other sharing⁠—and as thorough designers, we should give attention to how they appear in these environments, too.

What’s in the Head? – MDN
A general overview from our friends at MDN.
Metadata – web.dev
And the folks at Google.

We’ve gathered a handful of practices here which adjust and optimize how your site appears through these lenses, via special <link> and <meta> elements that live in your page’s <head>.

No site is truly complete without considering these! These are the “bow” to “wrap” your work.

Favicons and Touch Images

Chrome.

i⁠OS/Mobile Safari.

The first of these is the favicon (a portmanteau for favorite icon)⁠—which appears in the browser’s tabs/address bar, bookmarks, history, and also on search engine entries. This is often a logo⁠—though they don’t always translate down well in size. Sometimes it is its own thing! But it is always an important part of the initial impression of your site, and should be carefully considered and constructed.

How to Favicon in ~~2021~~ 2026
Pretty good, modern walkthrough.

The Humble `favicon.ico`

The base favicon format is .ico⁠—from ancient, bitmapped Windows icons. It is a package/directory/container format, meaning it can contain several, discrete, raster icon sizes: 16×16px, 32×32px, 64×64px, etc.

We’ll use different elements, later, for our other/larger needs!

These are still needed/used today because of several, long-standing browser quirks:

Browsers still look for a favicon.ico at the root of a domain! You may have noticed console errors.
These are used as a default/fallback option, if nothing is manually specified in your page <head>.
Safari (so namely, your i⁠OS visitors) only recently added support for the better SVG favicons, detailed below.

1. Drawing It

You should draw each size individually, when necessary⁠—pixel-tuning/nudging each path to land nicely on the pixel grid, so it is legible and crisp at its dimension. You can use Figma’s pixel preview (set at 1x), toggled with ⌘ ⇧ P.

Note that these can have transparent backgrounds, and that HiDPI (2x/retina) displays will render their device-native size⁠—so most folks are seeing your 32px version, these days. Export a PNG for each dimension, from Figma, into your project folder.

Draw an artboard/frame for each size.

2. Packaging It

These separate files can then be combined together in an .ico with ImageMagick⁠—the appropriately named Dark Arts tool way down at the bottom of nearly every online imaging pipeline.

On a Mac, you’ll use your Terminal to first to install Homebrew, and then use that to install ImageMagick. You can then run this command, in your project folder, which will yield a single favicon.ico file:

						magick 16.png 32.png 64.png favicon.ico

You can open a terminal from VS Code with ⌘ ⇧ C , or from GitHub Desktop with ⌃ ` .

3. Linking It

Even though browsers still look for it in the root, you can instead specify/include the resulting favicon.ico in your <head>, allowing you to organize/move it elsewhere:

						<head>
	<title>Typography & Interaction</title>
	<link href="assets/icons/favicon.ico" rel="icon" sizes="any">
	<!-- The rest of your head… -->
</head>

We’ve omitting the responsive viewport element here, for clarity. But your <head> should have this along with all your stylesheets and JS. Just the metadata, here.

A few other (…Safari) concerns:

Safari caches these dramatically⁠—meaning any changes are not reflected/updated for a very long time. It is extremely annoying.
It also doesn’t facilitate detecting light/dark mode, so your icon needs to be visible on both a light and dark toolbar/background.
It still occasionally decides to mat some icons that it doesn’t think have enough contrast, adding a white border. You can’t prevent or control this! Cool.

Safari (…sometimes) adds this white border!

Modern SVG⁠s

Modern browsers now support SVG⁠s for favicons, which gives us the benefit of the vector format⁠—resolution independence. One file, no intermediate/terminal steps, for different display sizes and densities. It is still a good practice to draw these at 16×16px⁠—so you can pixel-tune them⁠—then export from Figma, now as a .svg .

You should add them to your <head> as a progressive enhancement, after the previous <link>; older browsers will just ignore them:

						<head>
	<title>Typography & Interaction</title>
	<link href="assets/icons/favicon.ico" rel="icon" sizes="any">
	<link href="assets/icons/favicon.svg" rel="icon" type="image/svg+xml">
	<!-- The rest of your head… -->
</head>

Responsive Favicons

SVG⁠s have another benefit: since they can include self-contained, internal <style> elements⁠—we can alter/adjust our favicon with prefers-color-scheme (light/dark mode) media queries!

						<svg viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg">
	<style>
		.background { fill: gainsboro; }
		.foreground { fill: black; }

		@media (prefers-color-scheme: dark) {
			.background { fill: black; }
			.foreground { fill: gainsboro; }
		}
	</style>
	<rect class="background" width="32" height="32" rx="2" />
	<path class="foreground" d="M12.544 15.769C9.79325 17.6473 8.76829 19.3139 8.76829 20.9894C8.76829 23.6702 11.3 25.2222 13.3763 25.2222C14.5151 25.2222 16.2234 24.8519 17.9229 22.5767C15.7591 20.3721 13.8931 18.0441 12.544 15.769ZM19.9203 24.5079C18.5712 26.2275 16.4424 28 13.3763 28C9.70565 28 6 25.1781 6 20.9894C6 17.1799 9.17127 14.6755 11.2738 13.2822C10.5729 11.6508 10.1174 9.96649 10.1174 8.32628C10.1174 5.29277 11.9483 3 14.3925 3C17.187 3 19.4034 5.12522 19.4034 7.81481C19.4034 10.4691 17.0731 12.7972 14.883 14.2787C15.7328 15.7337 17.1257 17.7178 19.3596 20.0723C19.4998 19.7549 19.6312 19.4462 19.7451 19.1552C20.1831 18.0265 20.3408 17.3033 20.3408 17.3033C20.4809 16.6861 21.0241 16.2275 21.6811 16.2275C22.4433 16.2275 23.0653 16.8536 23.0653 17.6208C23.0653 17.7354 23.0477 17.8413 23.0215 17.9383C22.9426 18.291 22.4608 20.1429 21.4358 22.127C22.6886 23.291 24.0464 24.4286 25.4569 25.5044C25.7898 25.7601 26 26.1658 26 26.6155C26 27.3827 25.3868 28 24.6246 28C24.3092 28 24.0201 27.903 23.7924 27.7266C22.4433 26.7037 21.138 25.619 19.9203 24.5079ZM16.6351 7.81481C16.6351 6.63316 15.6364 5.7866 14.3925 5.7866C14.0596 5.7866 13.7442 5.93651 13.4639 6.30688C13.2887 6.53616 12.8769 7.18871 12.8769 8.32628C12.8769 9.13757 13.0521 10.284 13.6391 11.7743C14.3837 11.2363 15.9431 9.99295 16.4774 8.61728C16.5913 8.31746 16.6351 8.05291 16.6351 7.81481Z" />
</svg>

You would export your SVG from Figma, then manually add the <style> and .classes, in VS Code.

Default/light mode.

If we had a separate dark mode.

And `apple-touch-icon`

When the iPhone (with Mobile Safari) came on the scene in 2007, it added its own tag for webpage icons⁠—now commonly known as touch or share icons⁠—visible when adding pages to your home screen and in bookmarks, frequently-visited lists, and messages.

As everyone rushed to… respond to the iPhone, this syntax stuck and became the de facto standard⁠—meaning that even Windows/Android Chrome use the same rel="apple-touch-icon" syntax, and for similar uses. In lieu of larger/specific images (more on that below), you should think of this as your default share image.

Safari bookmarks/favorites.

This should be an opaque (no transparency) PNG, at around 512×512px. Again, add it in your <head>, below the others:

						<head>
	<title>Typography & Interaction</title>
	<link href="assets/icons/favicon.ico" rel="icon" sizes="any">
	<link href="assets/icons/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/icons/touch.png"  rel="apple-touch-icon">
	<!-- The rest of your head… -->
</head>

Other Metadata

As sharing contexts became more and more prevalent online, other approaches were developed to add additional information around pages in these scenarios⁠—using special <meta> tags in the <head>.

The Open Graph Protocol
The original spec.
Sharing Debugger - Meta for Developers
Check your cards without sharing.
Hey Meta
A simple, decent, non-Meta version.
Iframely URL Debugger
This one will show you everything.

Here, (ironically, pre-Meta) Facebook led the charge⁠—what the iPhone was for the mobile web, Facebook was for sharing. They developed and popularized the Open Graph protocol, which became the standard and is used now in many (usually, non-Facebook) contexts. (Here the word graph is used with the mathematical meaning.)

This type of added info, broadly, can be referred to as structured data or metadata⁠—hence Facebook’s name change!

Title and Description

Open Graph specifies og:title and og:description properties. However, we already have a <title> element⁠—and there was an existing convention around descriptions⁠—which browsers, apps, and search engines continue to use.

We generally think including redundant og: versions for title/description is unnecessary. (SEO/snake-oil folks might disagree.) If you are worried⁠—or your boss tells you to⁠—you could duplicate the tags. One reason might be to tailor different content (like your description length), for different platforms. But we don’t think it is worth it, most of the time!

Again, different apps are going to display and use this information in their own way⁠—so there are no hard rules on length, and you’ll want to check the contexts you care about. Generally, tweet-length (toot–length?) works well⁠—so somewhere around 140 characters.

We’ll add in a description, to our growing <head> stack:

						<head>
	<title>Typography & Interaction</title>
	<link href="assets/icons/favicon.ico" rel="icon" sizes="any">
	<link href="assets/icons/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/icons/touch.png"  rel="apple-touch-icon">
	<meta property="description" content="Typography &&nbsp;Interaction is&nbsp;a year-long, two-semester course in&nbsp;the MPS&nbsp;Communication Design program at Parsons&nbsp;/ The New School. The&nbsp;class will provide a&nbsp;rigorous foundation of&nbsp;typographic and interaction principles in&nbsp;the context of&nbsp;digital design.">
	<!-- The rest of your head… -->
</head>

Titles and descriptions should always be plain text⁠—no HTML inside. You can use use HTML character/entity references (like   for ragging) and most encoded Unicode symbols, though!

Image

In addition to your favicon and touch images, you can also specify an og:image (OG for Open Graph) in your <head>. This is often used for more page-specific images: the main photo for a news article, the product shot in e-commerce, and so on.

These are generally made visible when sharing a link on Facebook, LinkedIn, Slack, Messages, etc.⁠—where these sites/apps generate a share card or preview (also sometimes called an unfurl) for the URL:

Slack shows the whole image.

LinkedIn crops in to 16:9-ish.

These should be JPG⁠s (for more photographic content), or PNG⁠s (still opaque). Tradition/inertia suggests Facebook’s original 1200px × 630px dimension⁠—but every context/app handles these differently. A better, modern rule-of-thumb is an image around 1200px on the long edge, at its original/best aspect-ratio⁠—with a 16:9-ish “safe area” in the middle for any text. We might even do 2000px, these (HiDPI) days!

These are again specified in your <head>, now with <meta> elements⁠—importantly, with the full, absolute URL for the file:

						<head>
	<title>Week 22</title>
	<link href="assets/icons/favicon.ico" rel="icon" sizes="any">
	<link href="assets/icons/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/icons/touch.png"  rel="apple-touch-icon">
	<meta property="description" content="We’ll properly begin our fifth and final unit, If&nbsp;All You Have Is a&nbsp;Hammer, Everything Looks Like a&nbsp;Nail, with a&nbsp;discussion of last week’s&nbsp;reading.">
	<meta content="https://typography-interaction-2526.github.io/assets/meta/22.png" property="og:image">
	<meta content="Pale green background with black, vernacular “Gorton” text of the page title/date." property="og:image:alt" >
	<!-- The rest of your head… -->
</head>

Note the full URL⁠—and that these allow an og:image:alt text for better accessibility, in a separate tag.

Audio and Video

Some sharing contexts even let you play audio or video directly, in situ, from a share card. This might be useful for sites oriented around media, like Apple Music or YouTube⁠—but keep in mind the user is then not visiting the pages themselves, which you might prefer.

These are specified much like images, with the og:audio and og:video properties. There are extra metadata properties associated with the different types.

Conceptually, do you want your shared URL to function only as a link? Or somewhat as the thing itself?

Messages allows some inline media.

Schema and Web App Manifests

Beyond this, there is a (very, very) long tail of metadata/structured-data uses. Much of it will depend on the nature of your project/work, and there will be sub-conventions within conventions.

Schema.org
Another common structured-data format/collection.
Web App Manifests – MDN
Metadata for apps.
Intro to How Structured Data Markup Works
How Google uses these.

After Open Graph, the most common structures you might encounter next are probably Schema.org, oriented around search engine (Google) snippets⁠—and Web app manifests (manifest.json), used by progressive web apps. Whether these are necessary will depend on your project!

`charset`

This usually isn’t explicitly needed these days⁠—because browsers assume/default to it⁠—but you might have seen it in our examples and on other sites. This specifies your document’s character encoding as UTF-8, a superset of basic ASCII:

UTF-8 – Wikipedia
The most common, multi-lingual encoding, these days!

						<head>
	<meta charset="utf-8">
	<!-- The rest of your head… -->
</head>

Long story (very) short⁠—this allows you to use encoded non-latin characters (and emoji 👋) directly in your HTML! To be thorough/explicit (or if you are seeing weird character junk), you can include this tag.

`robots`

You can say⁠—well, again, really suggest⁠—that your site should not be indexed by search engines with the so-called “robots tag”:

						<head>
	<meta name="robots" content="noindex, nofollow">
	<!-- The rest of your head… -->
</head>

Keep in mind though⁠—if it is online, it can be scraped! Many bad actors (and “AI” companies) have shown this⁠—and other techniques, like robots.txt⁠—do not preclude your content from being indexed/ingested/reused. The web was a simpler place!

<meta name="robots"> – MDN
Suggest behaviors for ’bots.
robots.txt – Wikipedia
Same idea, in a separate file.