Dev

Fake CDN URL Set Generator

Realistic fake CDN URL sets are essential for testing asset pipelines, mocking API responses, and building frontend prototypes without touching production infrastructure. This fake CDN URL set generator produces plausible content delivery network URLs complete with versioned paths, content hashes, and proper file extensions across images, JavaScript bundles, CSS stylesheets, web fonts, and video files. Each URL mirrors the structure you'd see from real CDNs like Cloudfront, Fastly, or Cloudflare — making them drop-in substitutes during development. When you're building a UI component that renders a list of media assets, hardcoding the same URL for every item breaks realistic rendering tests. Generating a varied set of CDN URLs lets you verify that broken-image fallbacks trigger correctly, that lazy-loading intersects at the right scroll depth, and that your URL parser handles both hash-based and version-based path patterns. Content Security Policy testing is another common use case. CSP headers restrict which domains can serve assets, and you need a diverse pool of domain names and path structures to confirm your policy blocks or allows the right origins. These generated URLs cover multiple CDN hostnames so you can stress-test allow-list logic without spinning up real servers. Database seeding, fixture files, and Storybook stories all benefit from realistic-looking data. A URL like cdn3.assets-delivery.net/v2/fonts/inter-regular.a9c41d.woff2 reads as authentic in a design review or QA walkthrough, keeping stakeholders focused on the actual interface rather than placeholder data.

How to Use

  1. Set the Number of URLs input to how many CDN URLs your fixture or test needs.
  2. Choose a File Type from the dropdown — pick 'mixed' for variety or a specific type like 'image' or 'font' for uniform fixtures.
  3. Click Generate to produce the URL set with realistic domains, versioned paths, and content hashes.
  4. Copy the full list and paste directly into your fixture file, mock API handler, or database seed script.

Use Cases

  • •Testing Content Security Policy allow-lists with varied CDN domains
  • •Seeding a product database with realistic image and video asset URLs
  • •Populating Storybook stories with remote font and stylesheet references
  • •Verifying broken-image fallback UI across a grid of fake asset URLs
  • •Stress-testing URL parser logic against hash-based and version-based paths
  • •Mocking API responses for an asset management or DAM system
  • •Simulating cache-busting behavior in front-end build pipeline tests
  • •Generating fixture data for Jest or Playwright tests that check URL rendering

Tips

  • →Use 'mixed' file type when seeding a media library UI — varied extensions expose edge cases in icon rendering and MIME-type display logic.
  • →Generate 50+ URLs and import them as a JSON array in Storybook argTypes to get realistic pagination behavior without a real backend.
  • →When testing CSP, generate several batches and note the different CDN domains — use them to build both your allow-list and your block-list test cases.
  • →If your URL parser uses regex, specifically look for URLs with both a version segment (/v2/) and a hash suffix — some parsers handle one but silently drop the other.
  • →For Playwright visual tests, map each generated URL to a mocked network route returning a placeholder image so screenshots remain deterministic across runs.

FAQ

What is a CDN URL and what does it look like?

A CDN URL points to a file hosted on a content delivery network — a distributed system that serves assets from edge servers close to the user. They typically follow a pattern like cdn2.example-assets.net/v3/images/hero-bg.c4a91f2b.webp, including a subdomain, a version or hash segment, and a file-type extension.

Why do CDN URLs contain content hashes?

Content-hash suffixes like main.a3f92c1b.js allow browsers to cache files indefinitely — because the hash changes whenever the file changes, the new URL forces a fresh download. This pattern is standard in Webpack, Vite, and most modern bundlers. Generated URLs replicate this pattern so your parser and cache logic can be tested against it.

Can I actually fetch these generated URLs?

No. These are structurally realistic but entirely fictional URLs. The domains do not host real files. If you attempt to fetch them you will get DNS errors or connection timeouts. They are intended purely for mocking, testing, and populating dev fixtures.

What file types does the generator support?

You can generate URLs for images (jpg, webp, png, avif), JavaScript bundles, CSS stylesheets, web fonts (woff2, ttf), and video files (mp4, webm). Select 'mixed' to get a varied set across all types, or lock to a single type when you need a homogeneous fixture dataset.

How do I use these URLs in a Jest or Vitest test?

Paste the generated list into a JS array in your test fixture file. Reference individual items in unit tests that check URL validation, or spread the full array into a mock API response object. Because the URLs are structurally valid, any regex or URL constructor logic will parse them correctly.

Do the generated URLs simulate versioned paths vs hash paths?

Yes. The generator produces both patterns — versioned segments like /v2/ or /1.4.0/ and content-hash segments like .a3f92c1b before the extension. This gives you coverage for both CDN setups, which behave differently in cache invalidation and URL-matching logic.

Can I use these URLs to test image optimization pipelines?

Yes, with caveats. You can test that your pipeline correctly extracts domains, parses extensions, or rewrites URLs to pass through an image proxy. What you cannot test is the actual optimization transform, since the URLs don't resolve to real images. Combine these with a local mock server that returns placeholder images if you need end-to-end pipeline testing.