How to screenshot pagesbehind a login
without leaking a session
Dashboards, account pages and member areas are exactly the pages teams most want a record of — and exactly the ones a naive capture returns as a sign-in form.
Why your capture came back as a login form
A capture service visits your URL the way a stranger would: a fresh browser, no history, no session. For a public marketing page that is exactly right. For anything behind authentication it means the renderer sees what a logged-out visitor sees — usually a redirect to a sign-in form.
This surprises people because the page loads perfectly in their own browser. It does so because their browser is carrying a session cookie that the capture has no way of knowing about. Nothing is broken; the capture is simply an honest picture of an anonymous visit.
Closing that gap means giving the renderer the same evidence of identity that your browser sends — and doing it in a way you would be comfortable explaining to your security team.
Decide whether you should be capturing it at all
Access controls exist for a reason, and the capture tool is not the place to argue with them.
Before the mechanics, the boring question: are you entitled to capture this page? Three situations are common and only two of them are comfortable.
- Your own application. You own the account and the data. Capturing your own dashboard after a deploy is uncontroversial.
- A service you subscribe to, for your own records. Usually fine, but check the terms — some explicitly forbid automated access even to your own account.
- Someone else's private area. Do not. If you are reaching for a stolen or shared credential, the problem is not technical.
Three ways to give a renderer a session
The differences matter less for convenience than for what happens if something leaks.
There are only really three approaches, and they differ mostly in how much trust each one asks of you.
- Session cookies. You extract the cookie your browser already holds and attach it to the capture request. No credentials are ever sent to the capture service, and the access expires when the session does. This is the approach we support, through the custom request headers and cookies capability on paid plans.
- Request headers. Common for APIs and for applications that authenticate with a bearer token rather than a cookie. Mechanically identical from the renderer's point of view: an extra header on the request.
- Scripted sign-in. The renderer is given a username and password and drives the login form itself. Convenient, and the option we deliberately do not offer — it means handing a third party a live credential rather than a scoped, expiring token.
Making authenticated captures actually reliable
Assume the session will break, and make the breakage visible.
Authenticated captures fail in ways public ones do not, and almost all of them come down to the session ending without anyone noticing.
- Sessions expire. A schedule that worked for three weeks starts silently capturing a login page. Watch for the capture that suddenly gets much shorter or much smaller — that is usually a redirect.
- Concurrent-session limits. Some applications sign out your other sessions when a new one appears. If your own session keeps dropping, that is why.
- Two-factor prompts. A cookie taken after 2FA is usually fine; a fresh sign-in is not automatable, by design.
- Content that loads after authentication. Dashboards commonly render a shell first and fill it in afterwards, so give these pages more settling time than a static page needs.
Our stability controls — waits, timeouts and retries — matter more here than anywhere else, because a half-rendered dashboard looks plausible enough to go unnoticed in a report.
When not to authenticate at all
Authentication is worth avoiding when you can. Two alternatives cover more cases than people expect.
- A shareable link. Many applications can produce a read-only public URL for a dashboard or report. If one exists, use it: no secrets, no expiry, no security conversation.
- A dedicated read-only account. If you must authenticate, do it as a purpose-made account with the narrowest possible permissions, so a leaked session exposes a view rather than an administrator.
FAQ
Can I capture a page that needs a login on the free tool?
No. The free tools capture pages as an anonymous visitor sees them, so anything behind a sign-in shows the logged-out state. Custom request headers and cookies are a paid-plan capability.
Do you store the cookies I send?
They are used to perform the capture you asked for. Treat any credential you share with any third party as one you should be able to revoke, and prefer short-lived session cookies over long-lived tokens.
Why does my capture show the login page even though I sent a cookie?
Most often the cookie has expired, or it is scoped to a different domain or path than the URL being captured. Check the expiry first — it is the usual culprit.
Can scheduled captures use authentication too?
Yes. The headers and cookies are part of the stored profile, so every run of that schedule uses them — which is also why an expiring session shows up as a run of identical, useless captures.
TL;DR
A capture service arrives logged out, so authenticated pages come back as sign-in forms. Fix it by attaching the session cookie or header your browser already uses — not by handing over a password. Check you are entitled to capture the page, prefer a shareable link or a read-only account where one exists, and expect the session to expire eventually, so watch for the run where the captures quietly become login screens.