Registry Parser
← All articles

TypedPaths and TypedURLs: the RegRipper typedpaths plugin

7 min read

Most user-activity artifacts tell you what was opened. The two keys behind the RegRipper typedpaths and typedurls plugins tell you something narrower and, in front of a tribunal, more useful: what the user typed. A path or URL that lands in these keys did not arrive by double-click, by a recent-documents shortcut, or by a program writing on the user's behalf. Someone put their hands on the keyboard, typed an address into a bar, and pressed Enter. That distinction is the whole reason these keys carry the evidentiary weight they do.

TypedPaths: the Explorer address bar

The first key lives under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths in the user's NTUSER.DAT. Each value records something the user typed into the Explorer address bar (the breadcrumb bar at the top of a File Explorer window, which doubles as an editable address field when you click into it). The value names follow a fixed pattern: url1, url2, url3, and so on. The data is the literal string the user entered.

The naming is a Windows quirk, not a mistake on Microsoft's part: the same address-bar control backs both Explorer and the legacy browser, so the values are named url<n> even when the content is a filesystem path. Do not read anything into the word "url" here. The values are paths.

The typedpaths plugin reads exactly this. In this site's implementation the key path is Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths, and each value becomes a row with two columns: the value name (url1, url2, ...) and the typed path. There is no decoding, no binary structure to unpack, no timestamp inside the value. The data is a plain string and the plugin surfaces it as one.

What you find there is a high-signal record of deliberate navigation. A few representative entries:

url1   C:\Users\jdoe\Documents\Finance
url2   \\FILESRV01\share\HR\terminations
url3   D:\
url4   ftp://ftp.partner-vendor.net/outbound

The first is mundane. The second is not. \\FILESRV01\share\HR\terminations is a UNC path to a remote share, typed by hand. That is a user who knew the server name, knew the share, and knew the subfolder, and went there directly rather than browsing. The third is a removable or secondary volume. The fourth is an FTP endpoint reachable from Explorer. UNC paths and ftp:// targets are exactly the entries worth flagging, because they represent intent to reach something off the local disk that the user had to know about in advance.

TypedURLs and the parallel TypedURLsTime

The second key is HKCU\Software\Microsoft\Internet Explorer\TypedURLs. Same value-naming scheme: url1, url2, through urlN. Same idea: these are URLs the user typed into the Internet Explorer address bar (and, importantly, into legacy Edge and any control that hosts the same IE address-bar component) rather than reached by clicking a link, a favorite, or a history entry.

On Windows 8 and later there is a second key sitting alongside it: HKCU\Software\Microsoft\Internet Explorer\TypedURLsTime. This is the part analysts most often miss. TypedURLsTime holds one value per entry, keyed by the same url<n> name, and each value is an 8-byte FILETIME marking when that URL was last typed. The two keys are joined on the value name, not on order or position. So url3 in TypedURLs pairs with url3 in TypedURLsTime, and that pairing is what turns a list of URLs into a timeline.

The typedurls plugin in this parser does exactly that join. It reads both keys, builds a lookup from the TypedURLsTime values by name, and for each URL pulls the matching 8-byte FILETIME (decoded from the first eight bytes of the value data when the value is at least that long). The output has three columns: the entry name, the URL, and the typed time in UTC. The plugin carries an explicit note that the times come from the parallel TypedURLsTime key on Windows 8 and later — on Windows 7 and earlier, that companion key does not exist and you get the URLs with no timestamps. Treat the absence of TypedURLsTime as an OS-version signal, not as missing data.

A worked row looks like this:

Entry   url1
URL     https://webmail.partner-vendor.net/owa
Typed   2026-06-11 09:42:18 UTC

That is a user manually entering a webmail login, with a timestamp to the second. If your case turns on whether someone knowingly accessed a specific service, that single row is close to dispositive.

What the ordering means

Both keys use the url1..urlN convention, and the ordering is effectively most-recent-first: url1 is the most recently typed entry, with older entries pushed down the numbering. When a user types an address that already exists in the list, it is promoted back to url1 rather than duplicated. This matters for TypedPaths, which carries no per-entry timestamps at all — the numeric ordering is the only sequencing you get, so url1 is your most recent typed path and the rest descend from there. For TypedURLs on Win8+, you do not need to lean on the ordering, because TypedURLsTime gives you a real timestamp per entry. On Win7 and earlier, ordering is all you have for URLs too.

I would hedge on treating the numeric order as a strict, gapless sequence. It is reliable enough to say "url1 is newest," but I would not build a hard timeline out of the numbering alone when a real FILETIME is available. Use TypedURLsTime when it exists; fall back to ordering only when it does not.

Why these two prove intent

The reason both keys punch above their weight is attribution plus deliberateness. They live in NTUSER.DAT, so attribution to the profile owner is unambiguous — the same property that makes UserAssist and friends worth citing. But where most artifacts record that something was accessed, these record that something was typed. There is no programmatic path into TypedPaths or TypedURLs. A script does not populate them. A linked-file click does not populate them. Malware navigating on its own does not populate them. The shell and the browser write these entries only in response to a human typing into an address field and committing it.

That is the answer to the question that decides a lot of insider and acceptable-use cases: did the user knowingly go there? A file appearing in RecentDocs can be explained away as an accidental open or a thumbnail render. A UNC path in TypedPaths is much harder to wave off — the user typed the server name. A sensitive URL in TypedURLs with a TypedURLsTime to the second is harder still.

The limits

Be honest about what these keys do not cover, because opposing counsel will be.

Privacy tools clear them. CCleaner-class utilities, "clear history" actions, and browser privacy settings will wipe both keys. A cleared TypedURLs with a recent key write time and few or no values is itself a tell, but the typed entries themselves may be gone from the live hive. Pull NTUSER.DAT from VSS snapshots, and look at recovered unallocated cells in the hive — RegRipper's del plugin and yarp's recovery modes will surface deleted values.

Modern browsers do not write TypedURLs. This is the big one. TypedURLs is an Internet Explorer key. Chrome, Firefox, and Chromium-based Edge do not populate it — their typed-URL equivalent lives in each browser's own SQLite history (Chrome's urls table with typed_count, Firefox's places.sqlite), not in the registry. On a modern host where nobody touches IE or legacy Edge, TypedURLs will be sparse, stale, or empty, and that is expected. An empty TypedURLs is not evidence the user typed no URLs; it is evidence they did not type them into IE. Pivot to browser history for everything else.

TypedPaths has no timestamps. Only ordering. If you need to date a typed path, you are correlating against other artifacts — the shellbags, the LNK files in Recent\, MountPoints2 for the volume — not reading a FILETIME out of the key.

Tools

  • RegRipper's typedpaths plugin (source) dumps the Explorer typed-path values. One line per entry.
  • RegRipper's typedurls plugin (source) dumps the IE typed URLs; check whether your version joins TypedURLsTime, because not every iteration of the plugin does.
  • The parser on this site reads both keys as part of its tree view, and joins TypedURLs against TypedURLsTime by value name so the typed time appears next to each URL. You can analyze NTUSER.DAT in your browser without uploading the hive anywhere.
  • For the wider catalog, see the RegRipper plugins reference.

Make sure whatever tool you use surfaces the TypedURLsTime FILETIME and not just the URL string. A typed-URL list without timestamps is a fraction of the evidence. The timestamp is what lets you say not just that the user typed the address, but when — and "when" is usually the part the case turns on.