Plausible Analytics
Cookie-free web analytics in a sub-1KB script, open source, with the whole dashboard on one page.
What it does
| Scope and feature set | Plausible focuses exclusively on web analytics with a streamlined feature set designed to track page views, traffic sources, and basic user metrics without cookies. |
|---|---|
| Script weight and performance | Plausible uses a sub-1KB script that loads quickly and minimizes impact on page performance, emphasizing a lightweight footprint. |
| Privacy approach | Plausible is cookie-free by design, does not collect personal data, and is built specifically for GDPR and privacy regulation compliance without consent banners. |
| Dashboard design | Plausible presents all analytics on a single-page dashboard, offering a simple, at-a-glance view of website traffic and metrics. |
| Target use case | Plausible targets website owners, bloggers, and content publishers who need straightforward traffic analytics and privacy compliance. |
| Pricing model | Plausible operates on a subscription model based on monthly pageviews, with no free tier mentioned in the available data. |
Pick Plausible Analytics if
- You need a simple, privacy-first replacement for Google Analytics focused solely on web traffic
- You want the smallest possible performance impact with a sub-1KB tracking script
- You require cookie-free analytics that doesn't need consent banners for GDPR compliance
- You prefer a single-page dashboard that shows all metrics at a glance without complexity
Compare
Security headers: F, 10 out of 100
Number 79 of 95 in the ranking. Missing 8 of the 9 headers we check.
Below the B minimum (70/100) in our RFP clause. A buyer using it would ask for a dated fix for each missing header.
With these headers missing, plausible.io is more exposed to man-in-the-middle attacks, malicious JavaScript, redirected forms, hijacked payments and clickjacking.
Missing 8
-
Content-Security-Policy 0 of 25
Tells the browser which scripts may run on the page, where its forms may submit, and where it may send data.
Without it: This is the main defence against malicious JavaScript. If an attacker gets any script onto the page (through a bug, a compromised analytics tag, chat widget or ad, or a poisoned package), the browser runs it with the signed-in user's full access. It can capture what they type, quietly point a sign-in or checkout form at the attacker's server, and skim card numbers as they are entered. A strict policy blocks scripts it does not list, and its form-action and connect-src rules leave stolen data nowhere to go.
-
Strict-Transport-Security 0 of 20
Tells browsers to use HTTPS for this domain, every time, without trying plain HTTP first.
Without it: The site is open to man-in-the-middle attacks. The first request a user makes (typing the domain, following an old http:// link) can go out unencrypted, and anyone on the same network, such as café, hotel or airport Wi-Fi, can intercept it before the redirect to HTTPS. From there they can read passwords, session cookies and card numbers, serve a fake sign-in page, or inject their own JavaScript into the real one.
-
X-Content-Type-Options 0 of 10
Stops the browser guessing a file's type instead of trusting the type the server declared.
Without it: A file uploaded as an image or plain text can be reinterpreted as HTML or script and run inside the product's own origin: malicious JavaScript delivered through a harmless-looking upload feature.
-
Frame protection 0 of 10
X-Frame-Options or the CSP frame-ancestors directive: decides which sites may show this one inside a frame.
Without it: Clickjacking. Another site loads the product invisibly in a frame and lines its real buttons up under something the user wants to click, so a signed-in user approves a payment, changes their account email or grants access without seeing it.
-
Referrer-Policy 0 of 10
Limits how much of the current URL is passed to other sites when a user follows a link or the page loads a third-party resource.
Without it: Full URLs, including paths and query strings that can carry document IDs, search terms, customer names or reset tokens, can leak to every outside script, image host and outbound link. Recent browsers default to a safer policy; older ones and embedded webviews do not.
-
Cross-Origin-Opener-Policy 0 of 5
Cuts the link between the product's window and windows opened by, or opening, other sites.
Without it: A page that opens the product keeps a handle on its window and can later redirect it to a look-alike sign-in or payment page (tab-nabbing) while the user thinks they are still on the real site. It is also part of the isolation browsers need to defend against Spectre-style attacks.
-
Cross-Origin-Resource-Policy 0 of 5
Tells browsers which sites may load this site's resources.
Without it: Other sites can pull the product's responses into their own pages, which makes side-channel leaks of what a signed-in user can see easier.
-
No version disclosure 0 of 5
Keeps the Server and X-Powered-By headers from announcing exact software versions.
Without it: A header like "nginx/1.18.0" or "PHP/7.4" tells an attacker which known vulnerabilities to try, and flags possibly unpatched software to every automated scanner on the internet.
Sent 1
-
Permissions-Policy 10 of 10
interest-cohort=()