Why Stekpad runs in your browser and not on our servers
Every founder we talked to before building Stekpad assumed we would ship a cloud scraper. We chose to ship a browser extension instead. Here is the thinking.
Cloud scrapers have a trust problem
To scrape authenticated pages, a cloud scraper needs your session. That means uploading your LinkedIn cookie, your Gmail token, or your Stripe session to a server you do not control. Users tolerate this today because the alternative is worse, but they tolerate it reluctantly.
The trust cost compounds. Every month we see new reports of scraper companies getting breached, leaking user sessions, or quietly selling anonymized data to third parties. Users assume the worst and limit what they scrape accordingly.
Browsers are good enough now
Chrome Manifest V3 gave us the tools: scripting APIs, offscreen documents, declarativeNetRequest, native messaging. A Chrome extension in 2026 can do almost everything a cloud scraper can — with the added advantage that it already has the user session without asking for it.
We spent six months prototyping both architectures. The browser-first version was slower to build but dramatically easier to trust, cheaper to run, and more honest about what the tool actually does.
The tradeoff we accepted
Running in the browser means Stekpad needs Chrome open for local scrapes. For 24/7 automation, that is a limitation. We added an optional Cloud plan for users who need scheduled runs without their laptop on.
But for the 95% of use cases — operators running 100-500 scrapes per day — local is strictly better. Cheaper, safer, easier to debug. Our bet is that users who try local-first never go back.
Related on Stekpad
More in this cluster
Authenticated Scraping: Keep Your Session Credentials Local
Explains the privacy risk of cloud-based authenticated scrapers (credentials or session cookies stored on third-party servers, exposed to breaches or ToS violations). Contrasts with the browser-native model: the extension runs in your active session, reads the page, extracts data, and never sends cookies or credentials anywhere. Covers five common authenticated-page use cases: LinkedIn, Salesforce, internal dashboards, paywalled content, SaaS pricing pages. Includes a risk comparison table (cloud scraper vs browser-native).
How to Scrape LinkedIn Safely in 2026
Two-part post: (1) legal landscape — what hiQ v. LinkedIn established about public profile scraping, what LinkedIn's ToS says about automated access, and the practical risk level for typical use cases (sales prospecting, research); (2) technical how-to — using Stekpad's browser-native scraper to pull LinkedIn data without exposing credentials to a third-party server, rate-limiting best practices, and what fields are safe to extract. Positions running in your own browser session as the lowest-risk approach.
Authenticated Scraping: Scrape Pages You're Logged Into
Explains how Stekpad handles authenticated pages by running in the user's active browser session — no credential storage, no cookie forwarding to a remote server. Covers: supported sites (LinkedIn, Salesforce, internal tools, paywalled sites), limitations (CAPTCHA flows, 2FA mid-session), and best practices for stable authenticated scraping. Differentiates clearly from cloud scrapers that require credential sharing.
Authenticated scraping — your session, your browser, your data
Stekpad runs inside your browser and uses your existing login session to scrape authenticated pages, so your credentials never leave your machine — unlike hosted scrapers that require you to share cookies with a third-party server.