Smart Blur

Smart Blur is a privacy-focused browser extension for hiding sensitive information before and during screen sharing. The product page positions it around a simple promise: share your screen, not your personal data. It runs locally, requires no account, and says detected content is found and blurred on the device instead of uploaded to a cloud service. The free feature set focuses on deterministic on-page redaction. Smart Blur can blur emails, phone numbers, card numbers, IDs, and custom keyword matches across any website. Users can also click an element, drag a blur region, or select text when automatic patterns are not enough. That makes it useful for demos, support calls, QA walkthroughs, sales calls, bug reports, and screenshots where a page may expose customer, payment, or personal data. The Pro feature set adds local AI and screen-share workflow improvements. The product page says Pro can use local AI to detect names and addresses in plain text, auto-enable when a browser-based screen share starts, blur every tab and tab name through Share Shield, persist per-page blurs, bake blur into screenshots, and import or export settings. Smart Blur is designed for browsers and web apps. The page lists Chrome, Microsoft Edge, Brave, and Comet as supported browsers, with Chrome Web Store as the main install path. It also lists common workplace tools such as Gmail, Stripe, Salesforce, HubSpot, Notion, Slack, Jira, Linear, Google Sheets, Google Analytics, Intercom, and Figma as examples of surfaces where sensitive information can appear. The most important limitation is screen-share detection. The site says protection can switch on automatically when the share starts from a browser-based meeting app such as Google Meet, Zoom in the browser, Microsoft Teams in the browser, Discord, Loom, or Webex. If the user starts sharing from a native desktop app, the browser extension cannot detect that start event automatically, so the user must turn blur on manually. That is still useful, but teams should test the exact meeting flow before relying on it for sensitive demos. For OpenTools readers, the practical test is whether the project removes work from a real builder workflow. This listing focuses on documented setup paths, concrete capabilities, limits, pricing signals, and the kinds of teams that can safely use the product. Teams should still run their own review before using any agent-connected tool on sensitive data. Check what runs locally, what touches third-party APIs, which permissions are granted, and whether the workflow can be scoped to a test project before production use.