Shared logins are a productivity win and a distraction risk at the same time. Hand a teammate access to a session, and there’s nothing stopping them from wandering off to social media, ad-supported news sites, or a domain that has no business being open during work hours. The block page feature in Send.win solves this at the session level: instead of relying on router rules or a company-wide firewall policy, you attach a list of blocked URLs directly to an individual profile, so only that session enforces the restriction. Everything else on the machine keeps working normally.
This guide walks through exactly how the block page feature works in 2026, how to set it up in both the native Sendwin Browser desktop app and a cloud browser session, and how teams use it to keep shared and delegated sessions focused. We’ll also cover where it fits alongside Send.win’s broader session isolation model, and how the Automation API extends the same idea to scripted, unattended browser sessions.
What Is the Block Page Feature in Send.win Sessions?
Every Send.win session is an isolated browser profile — its own cookies, local storage, cache, fingerprint, and (optionally) its own proxy. The block page feature adds one more per-session control: a list of URLs or domains that, when visited inside that specific session, get intercepted and replaced with a block screen instead of loading the actual page.
Because the restriction is tied to the session rather than the whole browser or the whole device, you can run one profile with zero restrictions for your own daily browsing and a second, completely separate session — shared with a contractor, a family member, or a junior team member — with a strict block list applied. Neither session affects the other. That’s the same session isolation architecture that keeps cookies and fingerprints from leaking between profiles, just applied to access control instead of identity.
What Counts as a “Session” Here?
In Send.win, a session is any managed browser profile you create for a specific account, client, or purpose — a client’s Facebook Ads account, a shared team login, a kid’s YouTube profile, or a disposable profile you spin up for a single task. The block page feature applies per-session, not globally, which is the entire point: you decide exactly which profile gets restricted.
Why Block Specific Websites Inside a Session?
The use cases fall into a handful of recurring patterns:
- Shared or delegated logins. If you hand off a session to a VA, contractor, or new hire, blocking access to unrelated domains keeps their activity scoped to the task you assigned them.
- Focus and productivity. Some users create a dedicated “work” session with social media, news, and video sites blocked, and keep a separate unrestricted session for personal browsing — a lighter-weight version of dedicated distraction-blocking software.
- Kids and family devices. A block list on a child’s session is more flexible than router-level parental controls because it doesn’t affect anyone else using the same computer.
- Client and agency work. Agencies managing ad accounts or e-commerce storefronts on behalf of clients can restrict a session to only the domains the engagement actually requires, reducing the chance of accidental cross-contamination with unrelated sites.
- Compliance and internal policy. Regulated teams sometimes need to demonstrate that a specific login was never used to access categories of sites (gambling, competitor tools, personal webmail) — a session-scoped block list creates that boundary by design, not by trust.
- QA and testing sessions. When testing a script or automation flow, blocking everything except the target domain prevents the session from accidentally wandering into ads, redirects, or unrelated third-party pages mid-test.
Before You Begin
You’ll need an active Send.win account and at least one session already set up. If you haven’t created one yet, walk through creating sessions in Send.win first — it takes under a minute and the block page feature attaches to any session type, whether it’s running with a residential proxy, a datacenter proxy, or no proxy at all.
Decide upfront whether you’re blocking a handful of specific pages (e.g., a single competitor’s pricing page) or entire domains (e.g., all of facebook.com). Send.win’s block list accepts both full URLs and root domains, so plan your list before you start entering it — it’s faster to paste five domains at once than to add them one at a time while troubleshooting.
How to Set Up the Block Page Feature: Step-by-Step
The workflow is identical whether you’re running a cloud browser session or using the native Sendwin Browser desktop app — only the window chrome looks different. Here’s the process:
- Open Send.win — either a cloud browser session from your dashboard, or the Sendwin Browser desktop app if you have it installed.
- Select the session you want to restrict from your session list. You can apply a block list to as many or as few sessions as you like — it’s never applied browser-wide.
- Open that session’s Settings panel (usually a gear icon next to the session name).
- Find the Block List / Block URL option inside the settings. This is where the block page feature lives.
- Add the URLs or domains you want blocked, one per line. You can mix full page URLs with root domains in the same list.
- Save the settings. The next time that session tries to load a blocked address, it will show a block page instead of the live site — immediately, with no need to restart the session.
To remove a restriction later, go back into the same session’s settings, delete the entry from the block list, and save again. Changes take effect on the next page load inside that session.
Using the Block Page Feature in the Send.win Desktop App
The native Sendwin Browser desktop app (available for Windows, macOS, and Linux) runs sessions locally as full desktop browser windows with encrypted cloud sync, which makes it the better choice for shared workstations, kiosk-style setups, or any session where you want the block list enforced consistently across every device it’s used on. Session settings — including the block list — sync the same way between the desktop app and a cloud browser session, so a block list you configure on one device applies to that session everywhere you log into it.
Managing and Editing Your Blocked URL List
A few practical notes that save time once you’re running block lists across multiple sessions:
| Task | How to Handle It |
|---|---|
| Blocking a whole site | Add the root domain (e.g., facebook.com) rather than a single URL — subpages inherit the block. |
| Blocking one page only | Add the exact URL path if you only need to restrict a specific page, not the entire domain. |
| Temporary restrictions | Remove the entry from the block list rather than deleting the session — the rest of the profile’s cookies and history stay intact. |
| Auditing what’s blocked | Review each session’s settings panel periodically, especially for sessions shared with contractors who rotate frequently. |
| Copying a list to a new session | Keep your standard block list in a text file so you can paste it into new sessions quickly instead of retyping it. |
Block Page Feature vs Other Website-Blocking Methods
Session-level blocking isn’t the only way to restrict access to sites — here’s how it compares to the more common alternatives:
| Method | Scope | Best For | Downside |
|---|---|---|---|
| Send.win block page feature | Per session/profile | Shared logins, delegated accounts, focus sessions | Only affects that specific session, not other browsing on the device |
| Router/DNS-level blocking | Entire network | Whole-household or whole-office restrictions | Too blunt for per-person or per-account control; affects everyone |
| Browser extension blockers | Entire browser profile | Personal focus/productivity | Doesn’t isolate cookies or fingerprints between accounts — no session separation |
| OS-level parental controls | Entire device/user account | Family devices with one shared login | Hard to scope narrowly; usually requires separate OS user accounts |
The trade-off is straightforward: broader methods are simpler to set up once but can’t distinguish between “this login should be restricted” and “this login shouldn’t be.” Send.win’s approach costs a few extra minutes of setup per session but gives you exact control over which login is affected.
Common Mistakes to Avoid
- Blocking at the wrong level. Adding a full URL when you meant to block the whole domain (or vice versa) is the most common misconfiguration — double-check whether subpages need to be covered.
- Forgetting the block list is per-session. If you create a new session for the same purpose later, the old block list doesn’t carry over automatically — you’ll need to set it up again (or copy your saved list).
- Relying on it as your only security layer. The block page feature is an access-control convenience, not a substitute for strong passwords, 2FA, or proper credential hygiene on shared accounts.
- Not communicating the restriction. If you hand a blocked session to a teammate without telling them, expect a support ticket asking why “the site is broken.”
Using Block Pages Across Teams and Agencies
Where the block page feature really earns its keep is on Send.win’s Team plan, where multiple people work out of shared sessions. A common pattern: an agency lead sets up a client’s ad-account session, configures a block list covering unrelated or risky domains, and then shares that session with the team — every teammate who gets access inherits the same restrictions automatically, without needing individual configuration. Combined with role-based access, this means you can hand out working sessions to a growing team without each new person becoming a fresh point of risk.
Automating Consistent Blocklists with the Automation API
Manual browsing isn’t the only place session-level controls matter. Send.win’s Team plan includes an Automation API that lets you drive sessions programmatically with Selenium, Puppeteer, or Playwright — useful for scheduled scraping, QA regression suites, or repetitive account tasks that don’t need a human at the keyboard. Because block lists are attached to the session itself rather than to a manual browsing habit, a scripted session inherits the exact same restrictions as a human-operated one: if a domain is on the block list, an automated script hitting it gets the same block page a person would. That consistency matters when you’re running dozens of unattended sessions and need every one of them to respect the same access boundaries without re-implementing the logic in your automation code.
🏆 Send.win Verdict
If you’re sharing logins with contractors, teammates, or family members and want to control exactly what each session can reach, Send.win’s per-session block page feature is a simple, precise way to do it — without touching router settings or affecting your own unrestricted browsing. Pair it with session isolation, the native Desktop app for shared workstations, and the Automation API if you’re scripting sessions at scale, and you get one consistent access-control layer across every way your team touches a login.
Try Send.win free today — start your 30-day free trial, no credit card required, and set up your first restricted session in minutes.
Frequently Asked Questions
Does the block page feature affect my other Send.win sessions?
No. Block lists are configured per session, so restricting one profile has zero effect on any other session in your account. You can run an unrestricted personal session alongside a heavily restricted shared session at the same time.
Can I block an entire domain instead of a single page?
Yes. Add the root domain (for example, example.com) to the block list and every page under that domain will be intercepted, not just the exact URL you entered.
Will the person using the blocked session see an error, or a specific block page?
They’ll see a Send.win block page in place of the site content, rather than a generic browser error — making it clear the restriction is intentional rather than a broken connection.
Does the block page feature work in the Send.win Desktop app, or only in cloud browser sessions?
Both. Session settings, including block lists, are tied to the session itself and apply consistently whether that session is opened through the native Sendwin Browser desktop app for Windows, macOS, or Linux, or run as a cloud browser session with no install required.
Can I apply the same block list to multiple sessions at once?
Block lists are set individually per session. There’s no bulk-apply toggle across sessions today, so for a team standard, keep your block list saved in a text file and paste it into each new session as you create it.
Is the block page feature available on the free trial?
Session-level controls, including the block page feature, are available across Send.win’s plans. You can test it during the 30-day free trial (no credit card required) before deciding between the Pro plan at $9.99/mo or the Team plan at $29.99/mo, which adds shared sessions and the Automation API.
Does blocking a site inside a session also block it for automated scripts run via the Automation API?
Yes. Because the restriction lives at the session level, any automated browsing driven through Selenium, Puppeteer, or Playwright against that same session respects the same block list as manual browsing would.
Can I temporarily disable a block list without deleting it?
There’s no separate “pause” toggle — remove the entries you want to allow temporarily, then re-add them later. Keeping a saved copy of your standard list makes this quick to reverse.