The `history` permission explained: what an extension can dig out of your past
The history permission lets a browser extension read every site you visited — even before you installed it. Here's what it exposes and how to check yours.

Almost every scary extension permission is forward-looking. The tabs permission watches the sites you open from now on. Host permissions let an extension touch the pages you load going forward. They're nosy, but at least they start their clock the moment you click "Add to Chrome."
The history permission is different. It reads backwards. The instant an extension with this permission turns on, it can pull up every site you visited last week, last month, and — if your history goes back that far — last year. None of which it was around for.
That retroactive reach is what makes history worth pausing on. Let me walk through what it actually does, who legitimately needs it, and when it should give you second thoughts.
What the history permission actually means
When an extension asks for history, it's requesting access to the chrome.history API — the same database that powers your browser's own history page. During install, Chrome surfaces this as the warning "Read your browsing history." It's one of a small set of permissions (alongside tabs and webNavigation) that trip that exact line.
Here's the part most people miss: this isn't the live "what tab is open right now" view. It's the stored, searchable log of everywhere you've been. The browser keeps that log for months by default, and the history permission hands an extension a key to all of it.
Across the Extenshi catalog — 308,210 live listings as of the 2026-06-01 snapshot — only about 0.9% of extensions (2,913 of them) declare the history permission. It's rare. That rarity is useful information: when something asks for it, the request should match what the extension obviously does.
What it actually allows — the technical truth
The core call is chrome.history.search(). Per the Chrome developer docs, you hand it a text query and a time range, and it returns an array of history items. Each item carries the full URL, the page title, the time you last visited, a visitCount, and a typedCount — how many times you typed that address directly versus clicking a link.
Pass an empty query with a start time of zero and paginate, and you can dump the entire history database. Not a sample — the whole thing.
That metadata is more revealing than it sounds. visitCount shows which sites you return to obsessively. typedCount shows the ones you know by heart, which are usually the personal, logged-in ones — your bank, your email, your health portal. The timestamps reconstruct your daily rhythm: when you wake up, when you work, when you doom-scroll at 2 a.m.
There's also a write side. chrome.history.deleteUrl(), deleteRange(), and deleteAll() let an extension erase history, and addUrl() lets it inject fake entries. The onVisited and onVisitRemoved events let it react in real time as your history changes. So the permission isn't just read-only snooping — it can also quietly rewrite the record.
Who legitimately needs it
Plenty of useful extensions ask for history for honest reasons. Better history search tools let you fuzzy-find that article you read three weeks ago — they genuinely need to read the whole log. Privacy cleaners that auto-wipe specific sites need the delete calls. Time-tracking and digital-wellbeing tools build "where did my afternoon go" reports from visit data. Session and tab managers sometimes restore from history.
For these, the permission is the whole point of the product. A history-search extension that couldn't read history would be useless. That's the test I apply: does the extension's main job obviously require seeing your past browsing? If yes, the request is defensible.
When it should give you second thoughts
The concern is the mismatch. A theme, a wallpaper switcher, a screenshot tool, a simple calculator popup — none of these have any reason to read your full browsing history. When a small, single-purpose extension requests history, the permission is doing something other than serving you.
Two things make this worse than the forward-looking permissions I've written about. First is the retroactive scope. I covered how the tabs permission can log every URL you visit from now on — but history also exposes everything from before you installed the thing. There's no clean slate.
Second is sync. If you have browser sync turned on, the history from your phone and your other machines lives in the same local database the API reads. So an extension on your laptop can end up seeing sites you only ever opened on your phone. Most people never connect those dots.
And remember the broader pattern: a declared permission is a statement of capability, not proof of behavior. I dug into that gap in my piece on runtime tracking versus permissions. An extension that can read your history may never send it anywhere — or it may bundle it up and ship it off the moment it loads. The manifest alone won't tell you which.
How to check your own extensions
You don't need to reverse-engineer anything to get a handle on this.
- Open
chrome://extensions, click Details on each one, and look at the site-access and permissions section. If you see "Read your browsing history," that'shistory,tabs, orwebNavigationat work. - For every extension flagged that way, ask the mismatch question: does this thing's actual job need to know where I've been? A history manager — sure. A PDF converter — no.
- Check the "Allow in Incognito" toggle. If it's on for a history-reading extension, your private sessions feed the same database it can read. Turn it off unless you have a specific reason.
- If an extension fails the test, remove it. The history it already pulled is gone from your side, but cutting access stops the next read.
The fastest way to do this across all your extensions at once is to let a scanner cross-reference the declared permissions against what each extension actually is. That's exactly what Extenshi does — it flags the extensions whose permission footprint doesn't match their stated purpose, so you're not squinting at warning strings one by one.
The history permission isn't evil. For the right tool it's essential, and most of the 2,913 extensions that request it are probably fine. But it's the one permission that reaches into your past, and that earns it a second look — especially when the extension asking has no business knowing where you've been.
This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].
Related Articles
The `tabs` permission explained: what browser extensions can really see in your open tabs
The tabs permission lets Chrome extensions log every URL you visit in real time — no history permission needed. Here's what it does and how to audit yours.
The `cookies` permission explained: what browser extensions can really access in your sessions
The cookies permission lets extensions read, write, and delete cookies — including session tokens. Here's what that means for your accounts and how to check.
The `scripting` permission explained: what browser extensions can really inject into your pages
The scripting permission lets extensions run JavaScript on any page you visit — including your Zoom calls. Here's what that actually means for your privacy.
Runtime tracking explained: what browser extensions do that their permissions never show
An ACM study found 15.97% of extensions start third-party tracking within 60 seconds. Here's why the permission list never told you, and how to check.