Blog / Web Frameworks

How to Detect if a Website Uses Laravel (2026 Guide)

June 17, 2026 · 10 min read

Laravel is the most widely used PHP web framework, and it powers a huge slice of the modern PHP web: SaaS dashboards, admin panels, marketplaces, internal tools, and a long tail of agency-built business sites. Unlike a front-end library, Laravel runs on the server, so you cannot spot it by reading rendered HTML alone. The good news is that a default Laravel app leaves a clear, reliable fingerprint in its HTTP response — and once you know where to look, detection takes one request.

This guide covers two approaches: the manual method for checking a single site with curl, and the DetectZeStack API for confirming Laravel programmatically or scanning thousands of domains at once. Every code example is copy-pasteable and uses fields that actually exist in the API response.

What Is Laravel and Why Detect It

Laravel is a free, open-source PHP framework for building web applications, with conventions for routing, an ORM (Eloquent), a templating engine (Blade), queues, and authentication. Because it standardizes so much of an app's plumbing, "is this site Laravel?" is a useful question for several audiences:

All of them want the same answer in code: is this site built on Laravel, yes or no?

Signals That Reveal a Laravel Website

Laravel does not advertise itself with a footer badge, but a default installation emits several signals. The cookie signal is by far the strongest; the rest are supporting evidence that helps when an app has been hardened.

Cookies and Headers (laravel_session, XSRF-TOKEN)

This is the signal that matters. By default, every Laravel response that hits the web middleware group sets two cookies:

You can see both with a single curl -I, which fetches only the response headers:

$ curl -sI https://example.com | grep -i set-cookie
set-cookie: XSRF-TOKEN=eyJpdiI6Ii4uLiJ9...; expires=...; path=/; samesite=lax
set-cookie: laravel_session=eyJpdiI6Ii4uLiJ9...; expires=...; path=/; httponly; samesite=lax

Seeing laravel_session in a Set-Cookie header is, for practical purposes, proof the site is Laravel. The value is a long base64-looking string (Laravel's encrypted payload), the cookie is usually HttpOnly, and it almost always appears next to XSRF-TOKEN.

One more header worth checking is X-Powered-By. Laravel itself does not set it, but the underlying PHP runtime often does, which corroborates the PHP layer:

$ curl -sI https://example.com | grep -iE "x-powered-by|server"
x-powered-by: PHP/8.3.7
server: nginx

Why the cookie, not the HTML? Laravel renders pages server-side with Blade and ships them as plain HTML, so the markup of a Laravel app can look identical to any other PHP or even static site. The session cookie is set by the framework's middleware before your browser ever sees the body, which is why it is a more dependable signal than anything in the DOM.

HTML, Routing, and Error-Page Fingerprints

When you cannot rely on cookies (more on renamed cookies below), the response body still carries softer clues:

None of these is as reliable as the laravel_session cookie on its own, but together they raise confidence when the primary signal is missing.

DNS and Server-Side Clues

DNS will not tell you Laravel directly — it is application code, not infrastructure — but the surrounding stack often correlates. A Laravel site is frequently deployed on:

Treat DNS as context, not proof. It helps you understand where a Laravel app runs once you have already confirmed the framework from the cookie.

Manual Detection vs. an API

The curl -sI cookie check is perfect for a single site. It is free, instant, and needs nothing but a terminal. Where it falls down is volume and consistency:

That is the gap the DetectZeStack API fills: it runs the same cookie-and-header detection (plus DNS, TLS, and HTML fingerprinting) and hands back structured JSON.

Detect Laravel with the DetectZeStack API (curl Example)

Before wiring up a real key, you can confirm the response shape against the public /demo endpoint, which runs the same detector pipeline with no authentication. It is rate-limited but perfect for a smoke test:

curl -s "https://detectzestack.com/demo?url=https://example.com" | python3 -m json.tool

The response is a single JSON object. Trimmed to the relevant fields, a Laravel hit looks like this — note that because Laravel implies PHP, you typically get a PHP entry in the same response:

{
  "url": "https://example.com",
  "domain": "example.com",
  "technologies": [
    {
      "name": "Laravel",
      "categories": ["Web frameworks"],
      "confidence": 100,
      "description": "Laravel is a free, open-source PHP web framework.",
      "website": "https://laravel.com",
      "icon": "Laravel.svg",
      "source": "http",
      "version": "",
      "cpe": "cpe:2.3:a:laravel:laravel:*:*:*:*:*:*:*:*"
    },
    {
      "name": "PHP",
      "categories": ["Programming languages"],
      "confidence": 100,
      "description": "PHP is a general-purpose scripting language.",
      "website": "https://www.php.net",
      "icon": "PHP.svg",
      "source": "http",
      "version": "8.3.7",
      "cpe": "cpe:2.3:a:php:php:*:*:*:*:*:*:*:*"
    }
  ],
  "categories": { "Web frameworks": ["Laravel"], "Programming languages": ["PHP"] },
  "meta": { "status_code": 200, "tech_count": 11, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1523
}

For production usage, sign up on RapidAPI and call /analyze with your key. The endpoint returns the same shape as /demo but without the demo rate limit, and each call is counted against your monthly quota:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://example.com" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '.technologies[] | select(.name == "Laravel")'

If Laravel is detected, that pipe prints exactly the matching object. If it is not present, jq outputs nothing and the script exits cleanly — easy to wire into a shell pipeline that filters a list of domains.

Confirm a Single Technology with /check

When you only care about one technology, the /check endpoint is more direct than /analyze. It runs the same detection but answers a yes/no question with a ?tech= parameter, so you do not have to filter the array yourself:

curl -s "https://detectzestack.p.rapidapi.com/check?url=https://example.com&tech=Laravel" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com"

The response is a compact object built for exactly this question:

{
  "domain": "example.com",
  "technology": "Laravel",
  "detected": true,
  "confidence": 100,
  "version": "",
  "categories": ["Web frameworks"],
  "response_ms": 1187,
  "cached": false
}

The tech match is case-insensitive, and the returned technology field is the canonical name from the detector, so you can pass laravel and still get back Laravel. When the framework is absent, detected is false.

Reading the JSON Response

A few fields on the Laravel entry are worth understanding before you build on them:

The top-level response_ms and cached fields (note: not inside meta) tell you how long the scan took and whether it was served from cache. The meta object carries only status_code, tech_count, and scan_depth.

Detecting Laravel at Scale with Batch Analysis

The single-site call does not scale to a prospect list of thousands. For that, loop a list of domains through /check or /analyze and collect the hits. A minimal shell pattern that prints every Laravel site from a file of domains:

while read -r domain; do
  result=$(curl -s "https://detectzestack.p.rapidapi.com/check?url=https://$domain&tech=Laravel" \
    -H "x-rapidapi-key: $RAPIDAPI_KEY" \
    -H "x-rapidapi-host: detectzestack.p.rapidapi.com")
  detected=$(echo "$result" | jq -r '.detected')
  if [ "$detected" = "true" ]; then
    echo "$domain	Laravel"
  fi
done < domains.txt

If you would rather pull the whole stack per domain (database, CDN, analytics, JS framework, and Laravel together) so you only spend one request each, call /analyze and filter client-side. For high-throughput patterns, connection reuse, concurrency, and quota management, see Batch Scan 1,000 Websites for Tech Stack. The same approach underpins tech-detection lead enrichment when you are building targeted prospect lists.

Common Pitfalls and False Positives

Three situations regularly trip up Laravel detection. Recognizing them keeps your inventory honest.

Renamed or Disabled Session Cookies

Laravel lets you rename the session cookie in config/session.php (the cookie option), and some teams do so to reduce fingerprinting. When the cookie is renamed, the default laravel_session signal will not fire. Detection then falls back to softer signals (the CSRF meta tag, Livewire/Inertia markers, the PHP header), none of which is as reliable. A hardened Laravel site can legitimately come back as "PHP detected, framework unknown."

XSRF-TOKEN Alone Is Not Proof

The XSRF-TOKEN cookie name is conventional in the Laravel/Axios world but is not exclusive to Laravel — other stacks have adopted the same name for client-readable CSRF tokens. If you see XSRF-TOKEN without laravel_session, treat it as a hint, not a confirmation. The detector weights laravel_session as the primary signal for exactly this reason.

Cookies Set Later in the Flow

If you fetch only the home page and it is fully cached at a CDN edge, the origin's Set-Cookie may never reach you. Some apps only start a session on a route that touches it (login, a form, a dashboard). When a top-level scan comes back empty but you suspect Laravel, try a route that requires session state. This is one reason an API that follows redirects and handles these cases is more dependable than a single manual curl against the root URL.

Pro tip: Pair the framework answer with the rest of the stack. Laravel + MySQL + nginx + a Vite manifest tells a very different story (a modern, actively maintained app) than Laravel + an old PHP version with a Whoops page exposed (a neglected one). One /analyze call gives you all of it at once.

Conclusion and Next Steps

Detecting Laravel on a single site comes down to one reliable signal: the laravel_session cookie in the HTTP response, usually alongside XSRF-TOKEN. A quick curl -sI ... | grep -i set-cookie answers the question for one URL. Softer signals — the CSRF meta tag, Livewire and Inertia markers, the Whoops error page, and the PHP X-Powered-By header — help when a site has renamed its session cookie.

Detecting it across a portfolio takes one HTTP call per domain to /analyze or /check, which runs the same cookie-and-header detection and returns Laravel in the Web frameworks category as structured JSON, with PHP usually riding along. From there, the same call gives you every other piece of the stack: database, CDN, analytics, JavaScript framework, and more — one quota, one response shape, every technology in one shot.

Related Reading

Detect Laravel and Every Other Technology in One API Call

One HTTP request returns every framework, language, database, CDN, and analytics tag on a page — Laravel included, with its CPE for security work. 100 requests per month free. No credit card.

Get your free API key

Get API updates and tech detection tips

Join the mailing list. No spam, unsubscribe anytime.