Detect if a webpage is using Client-Side Rendering or Server-Side Rendering
Users
1,000
0 in 30 days
Rating
4.6 / 5
+0.05 in 30 days
Ratings
8
+1 in 30 days
Store rank
#27K
#22K among extensions
Version
4.3.0
updated 13 Oct 2026
Users
monthly, 2 years
Latest, 15 Oct 2026:1,000 usersMove the mouse over the chart for any month
Ratings count
monthly, 2 years
Latest, 15 Oct 2026:8 ratingsMove the mouse over the chart for any month
The Chrome Web Store rounds user counts down to the leading digit, so the user line moves in steps. The ratings count is exact and is the better signal of real adoption.
About CSR vs SSR Detector
Does Google see your content β or an empty div waiting for JavaScript?
Open the popup and the answer is already there. CSR vs SSR Detector compares the raw HTML your server sends against what the browser actually renders, and tells you how the page is built: Server-Side Rendered, Client-Side Rendered, or a hybrid (islands, partial hydration).
Then it tells you the parts nobody else does.
π WHO IT'S FOR
β’ SEO specialists β verify that crawlers get real content in the initial HTML, before it costs you rankings
β’ Developers β confirm your SSR/hydration setup actually works in production, or peek under the hood of any site
β’ Web architects β gather rendering-strategy evidence across competitors and inspirations
β‘ WHAT YOU GET
β’ A verdict with a confidence score β and every signal behind it, with the points it contributed and what it observed. No black box.
β’ RENDERED WHERE: built in the browser, rendered at build time, rendered once and served from a CDN cache, or rendered for this request β read from the document's own response headers, along with the CDN, cache state, age and TTFB
β’ REGIONS: which parts of the page the server sent and which ones JavaScript filled in, character by character. "#root gained 12,400 characters after the scripts ran" is a very different bug report from "CSR, 88%".
β’ Framework detection: which rendering framework or static-site generator built the page, backed by markers found in the served HTML
β’ Tech stack: CSS framework, state management, build tool and hosting provider
β’ Core Web Vitals: LCP, CLS, INP, TTFB measured on the live page
β’ SEO & accessibility spot-check: meta tags, Open Graph, structured data, alt-text coverage
β’ SSR/CSR/MIX badge right on the toolbar icon
β’ A DevTools panel ("Rendering") with the whole report at full width, re-running on every navigation
β’ History of recent analyses; export to JSON, CSV or Markdown, or copy a one-line summary into a pull request
π¬ HOW IT WORKS
The core method is direct evidence, not guesswork: the extension fetches the page's raw HTML and diffs it against the rendered DOM. Framework hydration markers, serialized state and timing signals refine the verdict β 15+ indicators combined into a weighted score you can inspect yourself. Delivery and region analysis are reported separately and never allowed to vote on the verdict, because how a document travelled is not the same question as where it was rendered.
π PRIVACY
Analysis runs locally in your browser. The extension optionally shares anonymous, aggregate statistics (rendering type, framework β never full URLs or page paths, only the site's origin) to power a public dashboard of rendering trends. One toggle in settings turns this off completely. Response headers and the region breakdown are never shared at all.
π Open source (MIT) β read the code, open an issue, or star it: github.com/dzienisz/chrome-ssr-csr