What is a link relation type?

A link relation type is a registered token (the rel value) that describes how a linked resource relates to the current one — for example rel=next points to the next page, rel=canonical points to the preferred URL. The same tokens are used in HTML and elements and in HTTP Link response headers.

Where can I use link relations besides HTML?

Link relations also appear in the HTTP Link header, which carries the same rel tokens for resources that are not HTML — such as paginated JSON APIs using rel=next and rel=prev, or rel=preload hints. The syntax is defined by RFC 8288 (Web Linking).

What is the difference between rel=canonical and rel=alternate?

rel=canonical declares the single preferred URL for the current content so search engines consolidate duplicates. rel=alternate points to a different representation of the same content — another language (with hreflang), a media variant, or an RSS/Atom feed. They serve opposite purposes.

Are link relation types case-sensitive?

Registered relation types are compared case-insensitively, but by convention they are written in lowercase. Extension relations expressed as URIs are compared as-is. Stick to lowercase registered tokens for interoperability.

Is anything I search uploaded?

No. The full registry and the search run entirely in your browser. Nothing you type is sent to any server.

HTTP Link Relation Types (IANA)

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

This is a searchable reference for IANA-registered HTTP link relation types — the rel tokens that describe how one resource relates to another. The same registry powers HTML <link rel="..."> and <a rel="..."> elements and the HTTP Link response header (RFC 8288), so a single list covers SEO tags, resource hints, pagination, and feed discovery.

How it works

A link relation answers “what is this linked thing to me?” The token goes in the rel attribute or Link header parameter:

<link rel="canonical" href="https://example.com/page">
<link rel="preload" href="/font.woff2" as="font" crossorigin>
Link: <https://api.example.com/items?page=2>; rel="next"

Relations come from several specs. Many are defined by the HTML standard (stylesheet, icon, preload, prefetch), others by RFC 8288 / RFC 5988 (next, prev, self, first, last), and SEO-oriented ones like canonical and alternate by their own RFCs and search-engine conventions. Tokens are matched case-insensitively; write them lowercase. Anything not in the registry should be expressed as a full URI (an extension relation) to avoid collisions.

Tips and example

Use the right relation for the job — search engines and browsers act on these:

canonical   → preferred URL (dedupe)            (SEO)
alternate   → other language/format/feed        (hreflang, RSS)
next / prev → pagination order                   (HTML + Link header)
preload     → fetch a critical subresource now   (resource hint)
prefetch    → fetch a likely-next resource later (resource hint)
nofollow / noopener / noreferrer → link safety + crawl control

For paginated JSON APIs, emit Link headers with rel="next", rel="prev", rel="first" and rel="last" so clients can follow pages without parsing the body. Everything runs in your browser; nothing is uploaded.