How to Tell if a Website Is Hosted on Vercel or Netlify

To tell whether a website is hosted on Vercel or Netlify, read its HTTP response headers — both platforms announce themselves clearly. Run curl -I https://example.com (or open the DevTools Network tab) and look: Vercel sends Server: Vercel along with an x-vercel-id and an x-vercel-cache header, while Netlify sends Server: Netlify and an x-nf-request-id. Whichever set appears names the platform, usually conclusively. You can corroborate with DNS: a domain whose CNAME points at cname.vercel-dns.com is on Vercel, and a Netlify CNAME target points to Netlify. This guide walks through every signal, how to read it, and what the platform tells you about the site.

It pairs with how to read a website's HTTP response headers and the broader how to find out where a website is hosted.

What Vercel and Netlify are

Vercel and Netlify are the two best-known frontend hosting / deployment platforms for the modern web. Both specialise in deploying static sites, Jamstack sites and JavaScript-framework applications straight from a Git repository, serving them from a global edge network with automatic builds, previews and HTTPS. Vercel is made by the company behind Next.js and is the default, most popular host for Next.js applications, though it hosts plenty else. Netlify pioneered much of the Jamstack workflow and hosts a wide range of static and framework-based sites. Because both run their own edge networks and add their own headers, they leave distinctive fingerprints — which is exactly what makes them easy to tell apart from each other and from traditional hosting.

Vercel signals

Vercel's fingerprint is a small cluster of headers that are unmistakable together.

Server: Vercel. Vercel sets its Server header to its own name, so this alone is a strong indicator.

x-vercel-id. This Vercel-specific header carries a request identifier that typically includes the edge region that handled the request (an airport-style location code) and a unique ID. No other platform emits this header, so its presence is close to definitive on its own.

x-vercel-cache. This shows the status of Vercel's edge cache for the response — values like HIT, MISS, STALE or PRERENDER. It tells you both that you are on Vercel and how the response was served from its cache.

Seeing Server: Vercel plus x-vercel-id is enough to call it; add x-vercel-cache and you have the full Vercel signature. If the site is also serving assets from /_next/static/ and inlining a __NEXT_DATA__ script, you are very likely looking at Next.js on Vercel, the most common pairing — the framework side of that is covered in how to tell if a website is built with Next.js.

Netlify signals

Netlify's fingerprint is just as clear.

Server: Netlify. Netlify sets its Server header to Netlify, directly naming the platform.

x-nf-request-id. A Netlify-specific request identifier — the nf stands for Netlify. Its presence names Netlify on its own.

Other x-nf- headers and *.netlify.app. Netlify deployments have historically exposed additional x-nf--prefixed headers, and the platform's default domains live under *.netlify.app, which can show up in redirects or asset URLs and corroborate the host.

As with Vercel, any one of the strong markers (Server: Netlify or x-nf-request-id) is a confident identification, and together they remove all doubt.

The signal table

Signal	Vercel	Netlify
Server header	Vercel	Netlify
Request-ID header	x-vercel-id (with edge region)	x-nf-request-id
Cache header	x-vercel-cache (HIT/MISS/STALE)	(varies; Netlify edge caching)
Default domain	*.vercel.app	*.netlify.app
Typical DNS CNAME	cname.vercel-dns.com	Netlify load balancer / *.netlify.app
Common framework pairing	Next.js (very common)	Wide range of static / Jamstack

A single strong header settles which platform you are on; the DNS and domain signals corroborate it.

Method 1: curl -I

The quickest check is one command:

curl -sI https://example.com

Read the headers. If you see Server: Vercel, x-vercel-id and x-vercel-cache, it is Vercel. If you see Server: Netlify and x-nf-request-id, it is Netlify. Because curl -I is scriptable, you can run it across a list of domains to sort which platform each uses. If the bare domain returns a redirect (301/302) to the www or https version, add -L to follow it (curl -sIL) so you read the final response's headers — the redirect itself may not carry the platform markers, a detail explained in the HTTP headers guide.

Method 2: the DevTools Network tab

In the browser, open DevTools (F12), go to the Network tab, reload, and click the main document request. The Response Headers panel lists Server, the request-ID header and the cache header — the same signals curl shows, in a visual layout. The Network tab also lets you inspect other requests: on a Next.js-on-Vercel site you will see the /_next/static/ chunks loading, which ties the hosting signal to the framework signal in one view. This is the friendliest method if you are already in the browser.

Method 3: DNS and CNAME lookup

DNS corroborates the headers and occasionally answers the question on its own. Run a lookup on the domain (and its www subdomain, since the apex often differs):

dig www.example.com CNAME
nslookup www.example.com

A CNAME pointing at cname.vercel-dns.com indicates Vercel; a CNAME pointing at a Netlify load balancer or a *.netlify.app target indicates Netlify. The apex domain may use A/ALIAS records rather than a CNAME, so check the www host too. DNS alone can be ambiguous when a site puts another CDN in front of the platform, so the most confident read combines the CNAME with the response headers — the technique outlined in how to find a website's IP address and the hosting guide.

Telling the two platforms apart at a glance

Because both are edge-hosted Jamstack platforms, people sometimes confuse them — but their headers make the distinction trivial, and a few habits keep you accurate. The single fastest discriminator is the request-ID header: x-vercel-id means Vercel, x-nf-request-id means Netlify, and you will never see both on the same response. The Server value is the next-clearest tell, since each names itself. Beyond the headers, the platforms diverge in default domains (*.vercel.app versus *.netlify.app), which surface in redirects, canonical tags or asset URLs and quietly confirm the host. And the framework context often points the way before you even read a header: a site clearly built with Next.js, serving /_next/static/ assets and an inline __NEXT_DATA__ script, is far more likely to be on Vercel (which makes Next.js), whereas a static-site-generator build — Hugo, Eleventy, Gatsby, Astro output — is a common Netlify profile. None of these contextual hints is proof on its own, but combined with the headers they let you call the platform instantly and explain why the team likely chose it.

Edge cases and what can confuse detection

A few situations are worth anticipating so a clean read does not trip you up. A third-party CDN in front of the platform is the main one: a team can put Cloudflare (or another CDN) ahead of Vercel or Netlify, in which case the outermost response headers belong to the fronting CDN and the platform markers may appear only on a deeper request, on specific asset responses, or be partly masked. When the outer headers look like a generic CDN, inspect individual asset requests in the Network tab and lean on DNS to recover the platform. Custom domains versus default domains: most production sites use a custom domain, so do not expect to see vercel.app/netlify.app in the address bar — that is normal, and the headers and CNAME are where the platform shows through. Apex versus www: the apex (root) domain often uses A or ALIAS records pointing at the platform's anycast addresses while the www host uses a clean CNAME, so always check the www subdomain's CNAME, not just the apex. And migrations and stale records: a site recently moved between platforms can briefly carry mixed signals, so trust the live response headers over a possibly-stale DNS cache. Recognising these cases keeps your detection both confident and honest about its limits.

A worked example

You are profiling a startup's marketing site. You run curl -sI https://www.example.com and the headers come back with Server: Vercel, an x-vercel-id showing an edge region code, and x-vercel-cache: HIT. That is the Vercel signature — confirmed. Curious about the framework, you open the Network tab and reload: a stream of /_next/static/chunks/*.js requests and a __NEXT_DATA__ script in the source tell you it is Next.js. Finally you run dig www.example.com CNAME and see cname.vercel-dns.com, which corroborates the host through DNS. The complete read: a Next.js application deployed on Vercel, served from Vercel's edge with caching active — a textbook modern frontend stack — and you assembled it in about a minute from headers, the Network tab and one DNS query.

What the platform tells you about a site

Identifying Vercel or Netlify is informative beyond the hosting label. Both signal a modern, Git-driven deployment model — automatic builds from a repository, preview deployments, edge delivery and automatic HTTPS — which says something about the team's engineering practices. Vercel strongly correlates with Next.js (Vercel makes it), so a Vercel host is a good prompt to check for Next.js specifically and to expect server-side rendering or static generation with edge functions. Netlify indicates a Jamstack or static-first approach across a broad set of frameworks and static-site generators. For competitive research the platform hints at the stack and the team's maturity; for sales qualification it identifies the deployment tooling in play; and for architecture understanding it tells you the site is built and shipped the modern way rather than via traditional server hosting. The hosting platform, in other words, is a compact clue to the whole frontend approach.

How reliable is Vercel/Netlify detection?

Highly reliable, because both platforms emit purpose-built, platform-specific headers (x-vercel-id, x-nf-request-id) that no one else uses, plus a self-naming Server value. The main thing to watch is the same one that affects all hosting detection: if a site places another CDN in front of the platform, the outermost headers may be the CDN's, and the platform markers might only appear on a deeper request or be partly masked — so check the document response carefully and corroborate with DNS. There is also the ordinary caveat that headers can in principle be customised, though it is rare for sites to strip these. In practice, when you see the Vercel or Netlify header cluster, you can state the platform with confidence; when a fronting CDN muddies it, lean on the CNAME and say what you can support.

The workflow

1. Run curl -sI https://example.com and read Server plus the request-ID and cache headers.
2. Match the signature — Vercel + x-vercel-id + x-vercel-cache, or Netlify + x-nf-request-id.
3. Open the Network tab to confirm and, for Vercel, spot Next.js (/_next/, __NEXT_DATA__).
4. Run a DNS/CNAME lookup (dig www.example.com CNAME) to corroborate the platform.
5. Allow for a fronting CDN — if the outer headers are a CDN's, check deeper and lean on DNS.

Go deeper

• The header reference: how to read a website's HTTP response headers.
• Where a site lives: how to find out where a website is hosted.
• The CDN question: how to tell if a website uses Cloudflare or another CDN.
• The whole stack: how to find out what technology a website uses.

Want the hosting platform, framework and full stack identified automatically? Analyse any site with StackOptic — one report, free, no sign-up.