The URL is the whole interface
Address a token and you have the link. Nothing to sign up for, no key, no generator to run: build it once, then post it wherever you were posting anyway.
The contract field takes an ENS name too: bleeps.eth is
that collection's contract. It is resolved here and the address is what
goes in the URL, never the name, since a name can be repointed and the
link would then mean something else. A token id may be typed in hex;
the URL carries the decimal form.
What gets posted is the card
The platform fetches that URL, reads the tags, and draws a preview from a plain JPEG the tags point at. Every thumbnail further down this page is that same image: same route, same bytes, rendered once and kept.
The page behind the card is the extra, not the point. Click through and the
SVG is live, an animation_url iframe replaces the still, onchain
audio gets a player, and the token's permanent address is spelled out. That
is what one visitor sees after the card has already done its work in front
of everybody else.
If you have somewhere of your own to put a picture, take the picture on its
own: embed.art/image/<token path> is a stable address for
the preview, usable as your own og:image or as a thumbnail, with
no page to scrape. It is how the examples below are rendered, and when the
art cannot be fetched it answers with a branded card rather than a broken
image.
If you have an ENS avatar, you already have a link
An ENS avatar can be set to an NFT you own. The record format
ENSIP-12 defines for that is
eip155:1/erc721:<contract>/<tokenId>, which is
character-for-character the path above. Put the domain in front of your
avatar record and it works.
Or skip the copying: embed.art/<name>.eth resolves the
record for you. If the avatar is an ordinary image rather than a token,
the page still shows it and says so. ERC-721 and ERC-1155 are both
supported, as ENSIP-12 requires.
Examples
Each thumbnail below is the card a platform would draw for that link. Where a token keeps its metadata decides whether it is still here, and how it wrote that down decides how long it stays reachable.
Metadata stored onchain, still resolving:
Half of these do not follow the standard, and that is ordinary
rather than unlucky. This page reads a token the way a browser
does, in two passes: fetch the tokenURI, then hand
image to an <img>, which fetches that
as a URL too. Mandalas, Bleeps and Nouns come through both passes
untouched, and no repair is made for them: Nouns base64-encodes, and
Bleeps writes %2520 precisely so that two decodes land on
the space it meant.
Brotchain, ArcadeGlyphs and the Moon do not encode their documents at
all, and each contains a # (a fill colour, always). A
browser reads that as the start of a fragment, so the very first pass
returns a fragment of the JSON and never reaches the artwork.
ArcadeGlyphs and the Moon also put the SVG itself in
image, where the schema asks for a URI pointing at one.
Those three render above anyway, because the page repairs the envelope
and then says so: the repair is named on that token's own page, and
?strict withdraws it and shows what a compliant client
gets instead. None of it is the artwork's fault, and none of it is the
owner's to suffer.
The Moon is unusual for a different reason: nothing about it was decided at mint. Its contract reads the current block, works out the lunar phase and returns the document to match, with no external resource involved at any point. The caveat there is ours rather than the token's, so it belongs here: Embed.Art caches a document the first time it is asked for, which makes that card the phase at that moment rather than tonight's. A token that rewrites itself is the case a cache does not fit.
Older than the standard, with no metadata document to read:
Autoglyphs are from 2019, and their tokenURI does not point
at a metadata document: it returns the piece itself, a 64 by 64 grid of
. O + X | - \ / and # as
text/plain. There is no image field anywhere
to fetch, because there is no document.
So Embed.Art draws it, and says on the page that it did. The characters
are not set in a typeface: each one is the vector primitive the
collection's own renderer uses, a slash being the cell's diagonal and
O its inscribed circle, which is what makes the strokes
join into continuous lines instead of a transcription. Asked with
?strict
it reports what a compliant client finds, which is a text file.
CryptoPunks gets the same treatment for the same reason, having no
tokenURI at all: its art comes from the collection's own
onchain renderer, and a punk arrives transparent, so what is behind it
is nobody's to invent.
* CryptoKitties is in this group on a
technicality, and the asterisk is the honest part. It has no
tokenURI either, so there is no document, and what the
contract holds is real: a 256-bit gene string, a generation, a birth
date, two parents. But the cat itself is not onchain. It is
drawn from those genes by CryptoKitties and served from their image
host, so unlike everything else in this group, that picture goes away
if the company does. Embed.Art names that host on the token's page
rather than passing the drawing off as chain data, and the address it
uses is the one the project's own API publishes for the token.
Metadata on IPFS, written down as one particular gateway:
Gone anyway. A server that stopped answering, and a hash nobody keeps:
Both are kept on purpose. Embed.Art cannot invent art that is gone, so it tells you exactly which URL stopped answering. An NFT is only as permanent as the least permanent thing it points at.
Roboto used to sit here. Nothing about the token changed: its
tokenURI hardcodes gateway.pinata.cloud, which is
read as the content address inside it and fetched from whichever gateway
answers. That fixes a courier, and only a courier.
CryptoDads shows the difference. Ten thousand profile pictures from 2021,
every token still owned, and all of them naming one CID under
bafybeief647gvyslgm… that ipfs.io, dweb.link, w3s.link
and nftstorage.link all give up looking for. A hash is a promise about
which bytes, never a promise that anyone is still holding them.
Content addressing takes the courier out of the trust list; it does not
remove the need for somebody, somewhere, to keep the file.
It is not an unlucky one, either, which is the uncomfortable part. Of 545 content-addressed collections sampled from 2021 and 2022 trading activity, 88 could not be fetched from any gateway: the survey, the raw data and the tool are here.