The best screen in most products sits behind a sign-in wall. Here is how Frametic captures it — a hosted browser you log into yourself, an encrypted session, and publishing that stays off by default.
Most products keep their best screen behind a sign-in wall. The marketing site shows a hero and some feature cards; the thing people actually buy — the dashboard, the editor, the inbox with real data in it — only exists after login.Any tool that captures a page by URL runs straight into that wall. It requests your app, gets redirected to a sign-in form, and screenshots the sign-in form.
Why this is awkward to solve
The obvious answer is "let the user provide credentials", and it is a bad answer. Asking people to hand over an email and password so a server can type them into their own product is a lot to ask, it breaks the moment there is a magic link or a two-factor prompt, and it means storing something you should never want to hold.What a capture actually needs is not your credentials. It needs the result of logging in: the session — cookies and local storage — that your browser holds afterwards.
A browser you log into yourself
So Frametic gives you one. Starting a session opens a real browser, running in the cloud, on your site's sign-in page, embedded directly in the studio. You drive it: type your email, click the magic link, complete two-factor, dismiss the onboarding tour — whatever your product requires. We never see the keystrokes; you are typing into a browser, not into a form we built.When you reach the logged-in page you press save, and Frametic snapshots the browser's session state: cookies (including the http-only ones a page script could never read) and per-origin local storage. Then the remote browser is destroyed.From that point on, captures reuse the saved session with our own headless browser. The hosted browser only exists during login, and again if the session expires and you re-authenticate.
How the session is stored
Encrypted at rest
Saved sessions are encrypted with AES-256-GCM before they are written to the database, and decrypted only in the capture step that needs them.
Two properties matter more than the algorithm. First, the session is scoped to the project it was saved on — it is used to capture that site and nothing else. Second, it is disposable: you can clear it whenever you want, and logging out of your own product invalidates it anyway, exactly as it would for any other browser you had signed in on.For simpler cases the same panel supports HTTP basic auth, custom request headers, and pasted cookies. Most people will not need them, which is why they live under an Advanced section.
The consent question
Capturing gated pages raises an obvious follow-up: what stops a private dashboard from ending up in public?The answer is that publishing is a separate, deliberate act. Every render is private when it finishes. Nothing appears in the community feed unless you explicitly publish it, and publishing asks you to confirm that you have the right to share what is on screen. We considered blocking authenticated captures from being published at all, and decided against it — plenty of people legitimately want to show off their own dashboard. What they need is not a prohibition, it is a default that never surprises them.So the default is off, and the affirmative step is yours.
A practical note
Real data makes a better video than dummy data, but it makes a worse public video. If you are recording a dashboard to share, the five minutes you spend setting up a demo account with plausible fake numbers will save you the screenshot of a customer's name in a launch post.Capture the real thing when the video is for you. Capture a demo account when it is for everyone else.
