The web-assets category ships the supporting files every website and web app carries, the ones you rarely author by hand but constantly need to test against. The favicon set has a multi-resolution .ico, a scalable SVG favicon, and an apple-touch-icon, plus Windows cursor (.cur) samples with real hotspots. The PWA set is a complete web app manifest with a full icon spread (192, 512, and a maskable variant), a cache-first service worker, and a browserconfig.xml tile definition. Social preview cards are rendered at the exact Open Graph (1200×630) and Twitter summary (1200×600) sizes. The crawler set covers robots.txt, an XML sitemap, humans.txt, and ads.txt, and the .well-known set has an RFC 9116 security.txt, an Apple app-site-association file, and an Android assetlinks.json. There's also an SVG symbol sprite paired with its PNG twin. Every file is a realistic, standards-compliant sample against fictional example.com data, for testing crawlers, PWA installers and manifest validators, favicon and icon pipelines, service-worker registration, link-preview generators, and .well-known parsers.
Filter web assets on Browse · 146 files · 11 subcategories
Favicons (multi-resolution .ico, SVG, apple-touch-icon, Windows .cur), a full PWA set (web app manifest, 192/512/maskable icons, a cache-first service worker, browserconfig.xml), social preview cards at exact Open Graph (1200×630) and Twitter (1200×600) sizes, crawler files (robots.txt, XML sitemap, humans.txt, ads.txt), and .well-known files.
An RFC 9116 security.txt, an Apple app-site-association file, and an Android assetlinks.json, realistic, standards-compliant samples against fictional example.com data.
They're samples for testing crawlers, PWA installers and manifest validators, favicon pipelines, service-worker registration, link-preview generators, and .well-known parsers, point your tooling at them rather than deploying them as-is.
A minified stylesheet closing with the CSS form of the annotation, `/*# sourceMappingURL= */` - the comment syntax differs from JavaScript's and is a common reason a CSS map is silently ignored. For testing stylesheet source-map resolution.
A one-line minified bundle built from two ES modules, ending in the `//# sourceMappingURL=` comment that points at the v3 map shipped beside it. For testing that a debugger, error reporter or bundler analyser follows the annotation and resolves the map relative to the bundle.
The same bundle with its v3 map embedded as a base64 data: URI in the sourceMappingURL comment - the single-file form dev builds emit. For testing that a tool decodes an inline map instead of trying to fetch it as a relative path.
An index map: instead of a top-level `mappings` string it carries a `sections` array of offset-and-map pairs, the form used when several independently built chunks are concatenated. For testing decoders that assume every map has mappings at the root.
A complete v3 source map for the minified bundle: two sources with their full original text inlined in sourcesContent, two names, and five VLQ-encoded mapping segments. For testing source-map decoders and stack-trace symbolication without any network fetch of the originals.
The v3 map for the minified stylesheet: one source with its text inlined, an empty names array, and three segments covering the selector and both declarations. For testing that a decoder handles maps with no names at all.
The same v3 map with the sourcesContent array removed, which is how most production builds ship: the mappings resolve but the original text has to be fetched from the paths in `sources`. For testing the fallback path of a debugger when originals are unavailable.
A deliberately invalid source map: version 2 instead of 3, a sources array longer than sourcesContent, a mapping segment that names an index outside `names`, and a `$` that is not in the base64 VLQ alphabet. For testing that a decoder validates the envelope before trusting the mappings.
A v3 map that resolves its sources through a `sourceRoot` scheme URL, uses `../` relative paths, leaves one sourcesContent entry null, and marks the second source as third-party via x_google_ignoreList. For testing URL joining and ignore-list support in a debugger.
Sample App .env: small deterministic fixture for parsers and the in-browser editor.
Sample Dockerfile: small deterministic fixture for parsers and the in-browser editor.
An IAB ads.txt listing authorised digital sellers with account IDs and relationships (sample data), for testing ads.txt parsers and ad-fraud tooling.
SAMPLE crawler/policy text file (ads-txt-sample) for bot and ads.txt parsers.
SAMPLE crawler/policy text file (app-ads-txt-sample) for bot and ads.txt parsers.
SAMPLE crawler/policy text file (humans-extended) for bot and ads.txt parsers.
SAMPLE crawler/policy text file (robots-ai-bots) for bot and ads.txt parsers.
SAMPLE crawler/policy text file (robots-disallow-admin) for bot and ads.txt parsers.
SAMPLE crawler/policy text file (security-txt-contact) for bot and ads.txt parsers.
A 500-URL sitemap served the way large sites serve them - gzip-compressed as sitemap-large.xml.gz. The gzip header carries mtime 0 and no embedded filename, so the bytes are stable across regenerations. For testing that a crawler decompresses .xml.gz sitemaps before parsing.
A humans.txt crediting the people and stack behind a site, in the conventional TEAM/SITE block format, for testing plain-text metadata parsers.
The plain-text sitemap format the sitemaps.org protocol also accepts: one absolute URL per line, no markup, UTF-8 encoded. For testing that a crawler supports the text form as well as XML.
A robots.txt with wildcard and per-agent rules, a crawl-delay, and a sitemap reference, for testing robots parsers and crawler policy handling.
A robots.txt that disallows the entire site for every crawler while allowing one media path for a single image agent. For testing full-block handling and the common misconception that a Disallow removes a URL from a search index.
A robots.txt carrying three different crawl-rate hints - an integer Crawl-delay, a fractional one alongside Request-rate and Visit-time, and a very large one - none of which are part of RFC 9309. For testing that a crawler reads or ignores rate hints without dropping the Disallow rules that share the group.
A robots.txt using upper-case, mixed-case and indented field names, a tab-indented rule, a value with no space after the colon, and both trailing and full-line comments. For testing that field names are treated case-insensitively while path values stay case-sensitive.
A robots.txt declaring five sitemaps - before the first group, inside two different groups, in lower case, gzipped, and on another host. For testing that a discovery crawler collects Sitemap as a file-global field instead of scoping it to the group it sits in.
A robots.txt where Googlebot is named by two separate groups and every Disallow has an equal-length Allow competing with it. For testing group merging, case-insensitive product tokens, and the rule that the most specific match wins with Allow breaking ties.
A robots.txt in which real Disallow rules are surrounded by Noindex, Host, Clean-param, Nofollow and two invented fields, several with inline comments. For testing that a parser skips fields it does not implement instead of aborting or mis-binding the rules that follow.
A robots.txt that begins with a UTF-8 byte-order mark, uses CRLF line endings, and leaves trailing spaces after two rule values. For testing the byte-level tolerances RFC 9309 requires - a leading BOM must be discarded rather than glued onto the first field name.
A robots.txt built entirely from pattern rules: `*` inside a path, `$` anchoring the end of a URL, a query-string pattern, and an Allow that carves one file out of a disallowed subtree. For testing that a robots parser implements RFC 9309 path matching rather than prefix comparison.
The single most common broken robots.txt in the wild: a server that answers /robots.txt with its HTML 404 page instead of a 404 status. For testing that a crawler treats unparseable markup as 'no robots.txt' and allows the site rather than inventing rules from tag names.
A deliberately invalid robots.txt: a rule before any group, an empty product token, an absolute URL where a path belongs, whitespace before the colon, a non-numeric Crawl-delay, and a line with no colon at all. For testing that a parser degrades line-by-line instead of failing the whole file.
A sitemap index listing three child sitemaps, one dated with a plain date, one with a full W3C datetime, and one with no lastmod at all. Two of the children ship alongside it, so a crawler can be walked from index to URL.
The first child of the sitemap index: six core URLs with a deliberately uneven mix of lastmod, changefreq and priority, including one entry that carries nothing but a loc. For testing that optional sitemap fields really are optional.
The second child of the sitemap index: six URLs dated with W3C datetimes in two different timezone offsets, including a changefreq of never and a priority of 0.1. For testing datetime normalisation and priority ordering.
A deliberately invalid hreflang cluster: an `en-UK` region that does not exist, an underscore locale, a German page that never links back, a Spanish self-reference dropped to http, and no x-default anywhere. For testing that an international audit reports each defect rather than the first one.
A sitemap whose three URLs form a complete hreflang cluster: every page lists every locale including itself and a shared x-default. This is the shape an international audit should pass, and the reference twin of the broken cluster.
A sitemap using the image extension namespace: six images across three pages, with and without titles and captions, in JPEG, WebP and AVIF. For testing extension-namespace parsing and image-discovery pipelines.
A two-URL news sitemap with publication name, language, publication date and headline for an English and a German article. For testing nested extension elements and per-article language handling.
A sitemap using the video extension namespace: one fully populated entry with duration, rating, view count, country restriction and tags, and one minimal entry with only the required children plus a player attribute. For testing video-sitemap parsers and their attribute handling.
A sitemap of URLs that need both layers of escaping the format demands: ampersands written as XML entities and reserved characters percent-encoded, plus a punycode host. For testing that a parser unescapes exactly once and does not double-decode.
An XML sitemap (sitemaps.org 0.9) with loc, lastmod, changefreq, and priority for several URLs, for testing sitemap parsers and crawl-scheduling tools.
A 32×32 Windows arrow cursor with its hotspot at the top-left tip (0,0), for testing .cur parsers, CSS custom cursors, and ICO/CUR converters.
A 32×32 Windows crosshair cursor with its hotspot at the centre (16,16), for testing cursor hotspot handling and .cur decoding.
A 180×180 opaque PNG apple-touch-icon (iOS rounds the corners itself), for testing home-screen icon extraction and Apple touch-icon handling.
A multi-resolution favicon.ico bundling 16, 32, 48, and 64 px images of the brand mark, for testing favicon parsers, ICO decoders, and multi-image icon handling.
A scalable SVG favicon of the brand mark: the modern crisp-at-any-size icon format, for testing SVG favicon support and vector-to-raster favicon pipelines.
The same four articles as Atom 1.0: tag: ids identical to the RSS twin, RFC 3339 published and updated timestamps, escaped HTML content, and both alternate and self links. For diffing an RSS-to-Atom converter against a known answer.
The third twin: the same four articles as JSON Feed 1.1, using the 1.1 `authors` array rather than the 1.0 singular form, with ids, URLs, summaries, HTML bodies and timestamps identical to the RSS and Atom files. The reference output for an XML-to-JSON feed converter.
Four articles of a fictional publication as RSS 2.0, with a self-referential atom:link, non-permalink tag: GUIDs, RFC 822 dates and full HTML bodies in content:encoded. One of three twins carrying identical content, so a feed converter can be diffed against a known answer.
Sample OPML Subscriptions: small deterministic fixture for parsers and the in-browser editor.
Page A of a deliberately invalid two-page canonical loop: A declares B canonical while B declares A canonical, so no page in the pair is its own canonical. For testing that a crawler detects the cycle instead of following it forever.
Page B of the deliberately invalid canonical loop, closing the cycle by naming page A as its canonical. Ships with page A so the loop can actually be traversed rather than described.
The baseline every canonical audit should pass: one self-referential canonical, an indexable robots meta, matching hreflang self-reference and an og:url that agrees with all of them. For use as the comparison reference against the conflicting pages in this set.
The English member of a correct three-locale hreflang cluster: it lists itself, both translations and the x-default, and its canonical agrees. Ships with the German page so reciprocity can be verified across real files.
The German member of the same cluster, with lang="de" on the html element and the identical alternate block. For testing that an audit compares the annotation set rather than the document language, and that the two agree.
A page that names itself canonical while telling robots not to index it, and then contradicts that again with an agent-specific googlebot meta that permits indexing. For testing directive precedence when a page argues with itself.
A deliberately invalid annotation block: `en-UK` is not a region code, `de_DE` uses an underscore, `zz` is not a language, one alternate has no hreflang attribute at all, one drops to http, there is no x-default, and the canonical points outside the cluster. For testing that every defect is reported, not just the first.
A deliberately invalid page carrying two canonical tags in the head and a third in the body. Search engines ignore body-level canonicals entirely and treat multiple head-level ones as a conflict. For testing that an extractor reports position as well as value.
A browserconfig.xml defining Windows Start-menu tile logos and colour, for testing MS tile configuration parsers and XML handling.
192×192 PWA icon SAMPLE for manifest icon pipelines.
512×512 PWA icon SAMPLE for manifest icon pipelines.
A 192×192 PNG app icon referenced by the web app manifest (purpose 'any'), for testing PWA icon pipelines and manifest icon resolution.
A 512×512 PNG app icon referenced by the web app manifest (purpose 'any'), for testing PWA icon pipelines and manifest icon resolution.
A 512×512 maskable PNG icon with the mark inside the central safe-zone and a full-bleed background, for testing maskable icon cropping across Android adaptive-icon shapes.
PWA shortcut descriptor SAMPLE #1 for install UI tests.
PWA shortcut descriptor SAMPLE #2 for install UI tests.
PWA shortcut descriptor SAMPLE #3 for install UI tests.
PWA shortcut descriptor SAMPLE #4 for install UI tests.
PWA shortcut descriptor SAMPLE #5 for install UI tests.
PWA shortcut descriptor SAMPLE #6 for install UI tests.
PWA shortcut descriptor SAMPLE #7 for install UI tests.
PWA shortcut descriptor SAMPLE #8 for install UI tests.
PWA shell fixture SAMPLE (app-shell.css) for offline app-shell testing.
PWA shell fixture SAMPLE (index-shell.html) for offline app-shell testing.
PWA shell fixture SAMPLE (offline.html) for offline app-shell testing.
PWA shell fixture SAMPLE (sw-register.js) for offline app-shell testing.
A sample cache-first service worker handling install, activate, and fetch events with an offline fallback, for testing service-worker registration, JS parsers, and PWA tooling.
Cache-first SAMPLE service worker for PWA offline-shell registration tests.
The smallest manifest that still satisfies a browser's install criteria: name, start_url, a standalone display mode and two PNG icons, with every optional member left out. For testing installability checks against the floor rather than a fully populated document.
A complete Progressive Web App manifest with a full icon spread, shortcuts, categories, and theme colours, for testing PWA installers, manifest validators, and JSON parsers.
A deliberately invalid manifest: start_url sits at /dashboard/ while scope is /app/, and a shortcut points at another origin entirely. Both are the kind of mistake that makes an installed app open in a browser tab. For testing scope-containment validation.
A manifest declaring a Web Share Target that accepts a POST of multipart form data, including two file parameters with MIME-type and extension accept lists. For testing share-target registration and the parameter renaming a share handler must perform.
A manifest registering the desktop-integration members: two file handlers with MIME and extension accept maps, a custom web+ protocol handler alongside mailto, a launch_handler client mode list, an Edge side-panel width and handle_links. For testing OS integration and manifest members a validator may not know.
A manifest with the members that turn a bare install prompt into a rich one: four screenshots split across wide, narrow and unspecified form factors, labels, categories and two shortcuts (one with its own icon). For testing rich-install eligibility rules.
A web app manifest whose icon array is built entirely from the awkward cases: a duplicate declaration, an entry with no sizes, sizes="any" on an SVG, a multi-size ICO, a .webp declared as image/png, a cross-origin icon and a 0x0 entry. For testing icon selection and validation logic.
A manifest exercising every icon `purpose` keyword: any, maskable, the space-separated combination, monochrome for a notification badge, and the obsolete `badge` value. For testing purpose parsing and adaptive-icon safe-zone handling.
A deliberately invalid manifest: well-formed JSON with an empty icons array, so it parses cleanly and then fails installability. For testing that a PWA validator distinguishes a parse error from an unmet install requirement.
PWA web app manifest SAMPLE for installability and manifest validators.
A 320×64 PNG icon sprite (five 64×64 cells): the raster twin of the SVG sprite, for testing background-position sprite techniques and sprite slicers.
An SVG sprite sheet defining five reusable icons as <symbol> elements referenced by <use href='#id'>, for testing SVG sprite pipelines and icon systems. Paired with a PNG sprite twin.
ads.txt: Wave G SAMPLE for crawler and .well-known tooling.
An Apple app-site-association file declaring Universal Links, web credentials, and app clips: normally served without an extension at /.well-known/, for testing AASA parsers (shown here as .json).
An Android Digital Asset Links file granting app-link handling to a package via a certificate fingerprint (sample), for testing assetlinks.json parsers and App Links verification.
change-password, Well-Known SAMPLE for crawler and .well-known tooling.
A sample machine-discoverable Do Not Track policy of the kind served at /.well-known/dnt-policy.txt, stating retention windows, exceptions and a contact for a fictional site. For testing crawlers and privacy scanners that look for the document and read its version header.
GPC: Global Privacy Control SAMPLE for crawler and .well-known tooling.
Host metadata in its original XRD form: a subject, an alias, an expiry, one property, and three Link elements including an lrdd template with a {uri} placeholder. Paired with the JRD twin that carries exactly the same data.
The JSON Resource Descriptor twin of the XRD host-meta: identical subject, alias, expiry, property and three links, expressed with lower-case JSON member names. For testing XRD-to-JRD conversion against a known answer.
humans.txt: Wave G SAMPLE for crawler and .well-known tooling.
The client-side twin of the Matrix delegation pair: homeserver and identity server base URLs plus an unregistered vendor key, which clients must carry through rather than reject. For testing discovery and unknown-member tolerance.
The one-member server-delegation document that lets example.com host its Matrix homeserver at matrix.example.com:8448 without changing user IDs. For testing federation discovery and explicit-port handling.
An SMTP MTA-STS policy in enforce mode listing three MX patterns, one of them a wildcard, with a seven-day max_age. RFC 8461 specifies CRLF line endings, so this fixture is written with them deliberately - for testing policy parsers that split on bare LF.
A fully populated RFC 8414 authorization-server metadata document for a fictional issuer: seven endpoints including PAR, introspection and dynamic registration, PKCE and DPoP algorithm lists, and policy URIs. Distinct from the minimal OpenID configuration already in this category.
robots.txt: Wave G SAMPLE for crawler and .well-known tooling.
Well-known security contact JSON SAMPLE #1.
Well-known security contact JSON SAMPLE #2.
Well-known security contact JSON SAMPLE #3.
Well-known security contact JSON SAMPLE #4.
Well-known security contact JSON SAMPLE #5.
Well-known security contact JSON SAMPLE #6.
Well-known security contact JSON SAMPLE #7.
Well-known security contact JSON SAMPLE #8.
An RFC 9116 security.txt with Contact, Expires, Encryption, and Policy fields: normally served at /.well-known/security.txt, for testing security.txt parsers.
RFC 9116 security.txt SAMPLE variant (security-txt-expired.txt) for well-known parsers.
RFC 9116 security.txt SAMPLE variant (security-txt-full.txt) for well-known parsers.
RFC 9116 security.txt SAMPLE variant (security-txt-minimal.txt) for well-known parsers.
RFC 9116 security.txt SAMPLE variant (security-txt-multi-contact.txt) for well-known parsers.
RFC 9116 security.txt SAMPLE variant (security-txt-pgp.txt) for well-known parsers.
A traffic-advice document opting a fictional origin into private prefetch proxy traffic at full fraction while disallowing every other agent. For testing prefetch-proxy discovery and the JSON-array (not object) top level this format uses.
.well-known SAMPLE JSON (assetlinks-extra) for crawler and client discovery tests.
.well-known SAMPLE JSON (change-password-rel) for crawler and client discovery tests.
.well-known SAMPLE JSON (gpc-policy) for crawler and client discovery tests.
.well-known SAMPLE JSON (nodeinfo-stub) for crawler and client discovery tests.
.well-known SAMPLE JSON (openid-configuration-min) for crawler and client discovery tests.
.well-known SAMPLE JSON (passkey-endpoints) for crawler and client discovery tests.
.well-known SAMPLE JSON (privacy-sandbox-attest) for crawler and client discovery tests.
.well-known SAMPLE JSON (related-website-set) for crawler and client discovery tests.
.well-known SAMPLE JSON (web-identity) for crawler and client discovery tests.
.well-known SAMPLE JSON (webfinger-resource) for crawler and client discovery tests.
Social
JSON-LD @graph with @id cross-references
A single @graph holding four nodes wired together by @id rather than by nesting - the shape most CMS plugins emit - including a SearchAction, a breadcrumb whose last item has no URL, and one reference to a product node that lives on another page. For testing graph flattening and reference resolution.
JSON-LD Event with offers and a location
A valid Event record for a hybrid event: both a physical Place with a postal address and geo coordinates and a VirtualLocation, plus a free Offer and a capacity. For testing array-valued properties and event date/timezone handling.
JSON-LD LocalBusiness with opening hours
A valid LocalBusiness (as a SportingGoodsStore subtype) with a postal address, geo coordinates, weekday and Saturday opening hours, and a 00:00-00:00 specification marking a holiday closure. For testing opening-hours parsing and the closed-all-day convention.
JSON-LD missing required properties (deliberately invalid)
A deliberately invalid Product record: no name, an Offer with a currency but no price, a brand with no @type, a Review with no rating, an AggregateRating with no ratingValue, and an availability given as a bare token instead of a schema.org URL. Valid JSON throughout, so the failure is semantic.
JSON-LD NewsArticle with author and publisher
A valid NewsArticle with two authors, a publisher whose logo carries explicit pixel dimensions, three images at the aspect ratios news results expect, and both publication and modification timestamps. For testing article extraction and date normalisation.
JSON-LD Product with Offer and AggregateRating
A valid Product record with a nested Offer carrying price, currency, availability, condition and shipping details, plus an AggregateRating. For testing rich-result validators and structured-data extractors against a document that should pass cleanly.
JSON-LD Recipe with steps and nutrition
A valid Recipe with ISO 8601 durations, four ingredients, and instructions that mix flat HowToStep nodes with a nested HowToSection. For testing duration parsing and recursive instruction extraction.
JSON-LD with wrong value types and a relative context (deliberately invalid)
A deliberately invalid Recipe carrying six unambiguously wrong-typed values - a numeric datePublished, a prose prepTime where an ISO 8601 duration belongs, an object recipeYield, two non-numeric ratings and a misspelled @type - plus a relative @context that never resolves, an untyped image object and two ingredients crammed into one string. For testing the limits of type coercion.
JSON-LD: Breadcrumb SAMPLE
schema.org JSON-LD SAMPLE (breadcrumb) for SEO/structured-data validators.
JSON-LD: Faq Page SAMPLE
schema.org JSON-LD SAMPLE (faq-page) for SEO/structured-data validators.
JSON-LD: Howto Step SAMPLE
schema.org JSON-LD SAMPLE (howto-step) for SEO/structured-data validators.
JSON-LD: Organization SAMPLE
schema.org JSON-LD SAMPLE (organization) for SEO/structured-data validators.
JSON-LD: Software App SAMPLE
schema.org JSON-LD SAMPLE (software-app) for SEO/structured-data validators.
JSON-LD: Web Page SAMPLE
schema.org JSON-LD SAMPLE (web-page) for SEO/structured-data validators.
Open Graph card (1200×630 PNG)
A 1200×630 Open Graph preview card at the exact og:image aspect ratio, for testing link-preview generators, social-card renderers, and image pipelines.
Twitter summary card (1200×600 PNG)
A 1200×600 Twitter summary-large-image card at the 2:1 aspect ratio, for testing Twitter/X card renderers and social preview pipelines.