Embed.Art

Embed Your Art Anywhere.

Post a link on Twitter, Facebook or Discord and nobody sees the link. They see a card the platform builds from its og: and twitter: meta tags, and those tags take one ordinary raster image, JPEG or PNG, at a fixed address. Not an SVG, not an animation, not ipfs://. So the art most worth sharing is the art that unfurls as nothing at all. Give the token an Embed.Art URL and it arrives with tags they can read.

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.

https://embed.art/eip155:<chainId>/erc721:<contract>/<tokenId>

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.

https://embed.art/
open

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:

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.