How to Tell if a Website Is Built with Laravel

If you want to know whether a website is built with Laravel, the fastest answer is to look at the cookies it sets: a default Laravel application sets an XSRF-TOKEN cookie and a laravel_session cookie, and seeing both is close to conclusive. The catch is that Laravel is a server-side PHP framework — it runs behind the scenes and sends finished HTML to the browser — so it leaves far fewer client-side fingerprints than a JavaScript framework like React or Next.js. You detect it from its side effects: cookies, response headers, public asset paths, and the occasional debug page. This guide walks through every signal, how to read it with the DevTools Application tab or a single curl -I, and the important caveat that a CDN or custom config can hide the tells.

It sits alongside the broader how to find out what technology a website uses and the language-focused how to find out what programming language a website uses, since Laravel is one of the most common ways a site ends up being a PHP application.

What Laravel is, briefly

Laravel is a popular open-source PHP framework for building web applications. It provides routing, an ORM (Eloquent), a templating engine (Blade), session and authentication handling, queues, and a large ecosystem of first-party packages. Because it is server-side, the work happens on the host: a request comes in, Laravel's PHP code runs, queries a database, renders a Blade template, and returns HTML to the browser. The browser never downloads "Laravel" the way it downloads a React bundle. That single fact shapes the entire detection approach — you are not looking for a script the framework ships to the client, you are looking for the traces a PHP server leaves in cookies, headers and URLs. The good news is that Laravel's defaults are consistent enough that those traces are recognisable.

Why server-side frameworks are harder to detect

It is worth stating the limitation up front, because it explains the method. A client-side framework announces itself loudly: it serves named JavaScript chunks, often inlines a data blob, and mounts into known DOM containers, all of which are visible in View Source and the Network tab. A server-side framework like Laravel does none of that. The HTML it returns is just HTML — there is no framework-branded asset for the browser to fetch. So instead of reading the framework directly, you read the evidence of how the page was produced: the session and CSRF cookies the framework sets, the headers the PHP runtime adds, the paths it uses for public files, and the distinctive error pages it shows when something breaks. Each is a strong hint; together they build a confident picture. This is the same "read the side effects" discipline that makes programming-language detection work for any server-side stack.

Signal 1: the cookies (the strongest tell)

Laravel's cookies are the single most reliable signal. A default Laravel app sets two cookies that matter:

• XSRF-TOKEN — Laravel sets this to support cross-site request forgery protection. The framework reads it back from a header on subsequent requests to verify the request is genuine. The name and the pattern are characteristic of Laravel.
• laravel_session — the default session cookie name Laravel uses to track a visitor's server-side session.

Seeing both of these is close to definitive. To check, open DevTools (F12), go to the Application tab, expand Cookies in the left sidebar, and read the cookie names for the site's domain. You can also catch them from the command line: curl -I https://example.com prints the response headers, and the Set-Cookie lines will show the cookie names. One nuance: the session cookie name is configurable, so a site could rename laravel_session to something custom — but the default name appearing, especially next to XSRF-TOKEN, is a clear positive. Absence is weaker evidence than presence here, because cookies may not be set until a session starts.

Signal 2: response headers

Headers offer corroboration. Laravel runs on PHP, so an X-Powered-By: PHP/8.x header (when present) tells you the application is PHP, which is consistent with Laravel even though it does not name the framework specifically. Some deployments also expose hints through the web server (Server: nginx or Apache) and through caching or session headers. The big caveat: X-Powered-By is frequently stripped for security, so its absence proves nothing about the backend. Reading these well is a skill in itself — the full method is in how to read a website's HTTP response headers. For Laravel specifically, treat a PHP X-Powered-By as supporting evidence that pairs with the cookies, not as a standalone proof.

Signal 3: public asset paths and /storage/

Laravel has conventions for where public files live, and those paths can show up in the HTML. The framework's public directory commonly serves user-uploaded and linked files from a /storage/ path (the result of Laravel's storage symlink), and compiled front-end assets often live under predictable folders. When you View Source or watch the Network tab, links to /storage/... for images and downloads are a Laravel-flavoured hint. They are not unique to Laravel the way /_next/ is unique to Next.js, so weight them as supporting rather than conclusive — but combined with the cookies they reinforce the read. Modern Laravel front-end builds frequently use Vite, so you may also see Vite's hashed asset output, which points to a current Laravel toolchain.

Signal 4: Blade, Livewire and Inertia markers

Laravel's templating and interactivity layers leave subtle markup tells. Blade is Laravel's template engine; it renders to plain HTML, so it is mostly invisible, but the surrounding stack often is not. Livewire — a popular Laravel library for dynamic interfaces without much JavaScript — injects recognisable attributes such as wire: directives and wire:id on elements, plus a Livewire script. Inertia.js — used to pair Laravel with a JavaScript front end like Vue or React — renders a <div id="app" data-page="..."> containing a JSON payload, which is a strong combined signal of Laravel-plus-Inertia. So while Blade itself hides, searching the source for wire: or an Inertia data-page attribute can reveal the framework and how its front end is built. This is also where Laravel detection connects to how to check what JavaScript libraries a website uses, because the front-end layer is often detectable even when the PHP backend is quiet.

Signal 5: the Ignition debug page

Occasionally a misconfigured Laravel site hands you the answer outright. When debug mode is accidentally left enabled in production and an error occurs, Laravel shows its distinctive Ignition error page — a styled stack trace that explicitly reveals the framework, often the Laravel version, and file paths. If you ever see that error screen, detection is settled. You should not try to trigger errors deliberately, but if a broken page surfaces an Ignition trace, it is a definitive (and, for the site owner, slightly embarrassing) confirmation. Treat it as a bonus signal you sometimes encounter rather than something to go hunting for.

The signal table

Signal	Where to find it	What it means
XSRF-TOKEN cookie	DevTools Application, Set-Cookie header	Laravel CSRF cookie — strong
laravel_session cookie	DevTools Application, Set-Cookie header	Default Laravel session cookie — strong
X-Powered-By: PHP/...	Response headers	PHP backend (consistent with Laravel) — often stripped
/storage/... asset links	View Source, Network tab	Laravel public storage convention — supporting
wire: attributes	View Source / Elements	Livewire (a Laravel library) — strong combined signal
<div id="app" data-page="...">	View Source	Inertia.js with Laravel — strong combined signal
Ignition error page	A broken page (if debug on)	Definitive when seen

No single supporting signal is conclusive on its own, but the cookies plus any one corroborator make a confident call.

Method 1: the DevTools Application and Network tabs

The most direct check is in DevTools. Open it (F12), go to the Application tab, and read the Cookies for the site — XSRF-TOKEN and laravel_session are what you want. Then switch to the Network tab, reload, click the main document request, and read the Response Headers for Set-Cookie and any X-Powered-By. While you are in the Network tab, note the asset paths (the /storage/ hint) and any Livewire script. This live view shows exactly what the server sets and sends, which is precisely where a server-side framework reveals itself.

Method 2: curl -I from the terminal

For a fast, scriptable check, use the command line. curl -I https://example.com performs a HEAD request and prints just the response headers, where you can read the Set-Cookie names and any X-Powered-By. Because some cookies are only set on a full request, you may prefer curl -sI on the homepage or a curl of the full page to capture everything. This approach is ideal for checking many URLs at once, and it cross-references neatly with header reading — see how to read a website's HTTP response headers for the wider technique. The terminal will not show you Blade or Livewire markup as readably as the browser, so pair it with a source view for the markup signals.

Method 3: View Source

A static source view catches the markup signals. Open the page, press Ctrl/Cmd + U, and search for wire: (Livewire), data-page (Inertia), and /storage/ (asset paths). You will not see "Laravel" written anywhere — Blade renders to ordinary HTML — but the surrounding ecosystem markers are visible. This method complements the cookie and header checks: the cookies confirm the framework, and the source confirms how its front end is constructed. Together they distinguish, say, a classic Blade-rendered Laravel app from a Laravel-plus-Inertia-plus-Vue setup.

A worked example

Suppose you are profiling a SaaS marketing site. You open DevTools, go to the Application tab, and under Cookies you see both XSRF-TOKEN and laravel_session — that alone is a strong Laravel signal. You confirm with curl -I, which shows the same cookie names in Set-Cookie and an X-Powered-By: PHP/8.2 header, consistent with a PHP app. Back in the browser, View Source reveals several elements carrying wire:id and wire:model attributes and a Livewire script — so the site uses Livewire for its interactive components. Image links point to /storage/uploads/..., matching Laravel's public storage convention. Every signal lines up: this is a Laravel application using Livewire, served by a PHP backend. In a couple of minutes you have the backend framework and the way its dynamic UI is built — a complete read of an otherwise quiet server-side stack.

Distinguishing Laravel from other PHP setups

PHP powers a lot of the web, so it is worth separating Laravel from its neighbours. WordPress is the giant of PHP, but it is a CMS with its own unmistakable tells (/wp-content/, /wp-json/), covered in how to tell what CMS a website is using — and it does not set laravel_session. Symfony, another major PHP framework, has its own cookie and header conventions (and Laravel is itself built partly on Symfony components, so some lower-level traces overlap). Plain PHP or older frameworks set a generic PHPSESSID session cookie rather than laravel_session. So the discriminating question among PHP sites is: which cookies and conventions are present. A laravel_session plus XSRF-TOKEN says Laravel; a PHPSESSID alone says a different PHP app; /wp-content/ says WordPress. Reading the specific names, not just "it's PHP", is what pins down Laravel.

What knowing it's Laravel tells you

The framework is an informative single fact. Laravel signals a PHP application built by a team using a modern, mainstream, well-supported framework — which says something about technical maturity and the developer talent in play. It implies an Eloquent/MySQL-style data layer, Blade templating, and often a particular front-end pairing (Livewire for server-driven UI, or Inertia with Vue/React for a richer client). For competitive research it reveals how a rival builds; for sales qualification it identifies the stack and the kind of integrations a prospect can support; for hiring and partnerships it signals the skills required. And because Laravel is so common in the PHP world, spotting it narrows a lot of follow-up questions about how the application is likely structured. This is exactly the kind of signal that feeds technographic qualification.

How reliable is Laravel detection?

Reliable when the signals are present, but honest about its blind spots. The XSRF-TOKEN and laravel_session cookies are intrinsic to a default Laravel install, so when you see them, confidence is high — and a Livewire or Inertia marker on top makes it near-certain. The blind spots are configuration and infrastructure: a team can rename the session cookie, strip X-Powered-By, disable debug pages, and front the app with a CDN or reverse proxy that masks or rewrites some signals, leaving a quieter footprint. So presence is strong evidence, absence is weak evidence — not seeing laravel_session does not mean the site is not Laravel, only that the default tell is not exposed where you looked. Combine the cookies, headers, asset paths and any markup markers, and where two or more agree you can state "this is Laravel" with genuine confidence; where they conflict or are absent, report the uncertainty rather than guessing.

The workflow

1. Open the Application tab and read cookies for XSRF-TOKEN and laravel_session.
2. Run curl -I to confirm the Set-Cookie names and check for an X-Powered-By: PHP header.
3. View Source for wire: (Livewire), data-page (Inertia) and /storage/ asset links.
4. Note any Ignition error page as a definitive confirmation if you happen to see one.
5. Combine the signals — cookies plus one corroborator means Laravel with confidence.

Go deeper

• The whole stack: how to find out what technology a website uses.
• The language underneath: how to find out what programming language a website uses.
• The headers that corroborate it: how to read a website's HTTP response headers.
• The front-end layer on top: how to check what JavaScript libraries a website uses.

Want the backend framework, language and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.