Microsoft Edge Browsing History File Location

Where Edge Keeps Your History and Why It Might Not Be What You Think

The Microsoft Edge Browsing History File Location is a file sitting on your local machine called History with no extension, buried inside the user data folder. That's it. No JSON, no SQL dump you can just open in a text editor and read line by line. It's a SQLite database, same as Chrome uses. Edge just calls its profile folder something different. The path is: C:\Users\[YourUsername]\AppData\Local\Microsoft\Edge\User Data\Default\History

Replace [YourUsername] with your actual Windows account name. The AppData folder is hidden by default, so you'll either need to type that path directly into the address bar of File Explorer or turn on "Show hidden files" in View settings. Most people lose time before they even get to the file because they stop searching once they can't see the folder. If you have multiple Edge profiles, the Default folder isn't always the one you want. Each profile gets its own named folder—Profile 1, Profile 2, and so on. The History file inside each one corresponds to that profile's browsing session. I spent about twenty minutes pulling my hair out once trying to find history from a work profile, only to realize I was looking in Default while my actual session was sitting in a folder literally called "Work Profile." Check which profile you're logged into before assuming Default has what you need.

Accessing the Microsoft Edge Browsing History File Location Properly

You can't just double-click the History file and read it. It's a locked SQLite database, and Edge holds an exclusive lock on it while the browser is running. If you try to copy it while Edge is open, you'll get an access denied error or end up with a corrupted snapshot. Close Edge completely first. Task Manager is your friend here—make sure no msedge.exe processes are still lingering in the background, because Edge likes to keep tabs alive even after you close the window. Once the browser is actually shut down, open a tool like DB Browser for SQLite, navigate to the file, and you can run queries against it. The main table you care about is called urls. It stores the ID, the URL string, the title, visit count, and a last_visit_time field. That timestamp is stored as a Windows FILETIME value—microseconds since January 1, 1601 UTC—which means it looks like a giant nonsensical number when you first see it. A quick online converter or a short Python one-liner will translate it into something readable. There's also a visits table that records every individual page load, including navigation type, transition qualifiers, and timestamps. This is where you can distinguish between a typed URL, a link click, a redirect, or a form submission. The transition field uses bit flags, so you'll see values like 1 for link click, 4 for typed, and 16 for a programmatic redirect. It's not immediately intuitive but it's consistent across Chromium browsers.

Edge also keeps a separate file called History-journal in the same folder. This is a Write-Ahead Logging journal that Edge uses to maintain consistency during writes. You don't need to touch it, but if you're doing forensic recovery and the main History file is damaged, that journal can occasionally help you reconstruct partial entries. It's fragmented and not human-readable on its own, so don't expect miracles, but it's worth keeping in the same directory as the main file if you're doing recovery work.

What Actually Gets Stored and What Doesn't

Edge records the full URL, the page title, how many times you visited it, and when the most recent visit occurred. It does not record search queries separately from the URL itself. If you searched Google for "weather tomorrow," the query is embedded in the URL string as a parameter—there's no dedicated search_terms column like you'd find in some third-party trackers. You just have to parse the URL to extract it. Here's something most people miss: the last_visit_time value for the top-level page in a tab is updated whenever you navigate away from it, even if you never close the tab. So a page that's been sitting open in an inactive tab for three days will show that three-day-old timestamp as its last visit time. The visits table has the accurate per-tab navigation records, but the urls table aggregates at the page level. If you're doing anything time-sensitive—like trying to prove you visited a site at a particular moment—the urls table alone will mislead you. Always join against the visits table for accuracy. Another practical limitation: if you're using InPrivate browsing, there is no History file to find. Edge clears all in-memory history when you close the InPrivate window, and no persistent History database is written to disk for that session. This is by design and it's non-negotiable. Some people ask if they can recover InPrivate history through the prefetch or cache folders. You generally can't in any meaningful way. The cache stores page resources, not navigation records, and the bits are obfuscated enough that reconstruction is more guesswork than analysis.

Synced history is a different beast entirely. If you're signed into Edge with sync enabled, your browsing history is stored in Microsoft's cloud, not just locally. The local History file reflects only what's been synced to this machine so far, and there's a sync engine that periodically pulls new entries. This means if you deleted history on another device, the local file might not catch up to that deletion immediately. I've had clients report missing entries that turned out to be pending sync deletes from a phone they used earlier that day. It's worth checking the sync status in Edge settings before assuming the local file is the source of truth.

Practical Workarounds and Where This Approach Breaks Down

The biggest issue people run into is permissions. Even after closing Edge, Windows sometimes keeps the file locked due to a pending system restore point or a shadow copy operation. The workaround is to boot into Safe Mode or use a live Linux USB and access the file from there. That sounds extreme for a simple lookup, but it's faster than troubleshooting file locks. Alternatively, you can use the built-in Edge export feature—go to Settings, History, and there's an export button that gives you an HTML file. It's not as detailed as querying the database directly, but it's immediate and requires no tools. For large-scale extraction, Python with the sqlite3 module is the standard approach. You don't need any special libraries. A basic query like SELECT url, title, datetime(last_visit_time/1000000-11644473600, 'unixepoch') FROM urls ORDER BY last_visit_time DESC runs in under a second on a typical user profile with a few thousand entries. A profile with tens of thousands of URLs might take ten to fifteen seconds depending on your drive speed. Solid state drives make a noticeable difference here. The one scenario where this entire method fails completely is when the History file has been manually deleted or overwritten. There's no recycle bin equivalent for the Edge data folder in most cases—people usually use a cleanup tool that trashes it. Standard file recovery utilities like Recuva or Disk Drill can sometimes pull the original file back if the disk space hasn't been overwritten yet, but success rates drop dramatically after 24 to 48 hours of normal system use. If you need that file for legal or compliance reasons, stop using the machine immediately and image the drive. That's the only reliable path.