A .lnk shortcut looks like a harmless pointer to a program or document, but it is one of the richest small forensic artifacts on Windows. It stores the absolute path of its target - normally including your account username - and, when Explorer created it, the MAC address and computer name of the machine it was made on. People attach .lnk files to emails and archives without realising any of that travels with them.
Scan a Windows shortcut fileThe core of the file is the target path. A shortcut records the full absolute location it points to, which on Windows almost always runs through C:\Users\<name>\..., so the account username and the folder layout come straight out. The working directory is stored separately and usually leaks the same thing. If the target lived on a network share, the UNC path (\\server\share) is recorded too, naming an internal server.
When Explorer creates a shortcut it stamps in a link-tracking (TrackerData) block, and this is where the shortcut turns into a fingerprint. It holds the NetBIOS name of the computer the shortcut was made on, and - decoded from a version-1 UUID - the MAC address of that machine's network card. A MAC address identifies one specific physical interface, so this ties the file to an actual device, not just an account.
That tracking block carries two identities: the current one and a "birth" one, stamped when the file was first created. When they differ, the scan reports that the target was moved or copied after creation, and recovers the original MAC address and original creation time from the birth record - so even a file that has been relocated to a different machine still points back at where it truly came from. The UUID also embeds a hidden sub-microsecond creation timestamp, separate from the file-system dates.
Alongside those, the scan reads the disk's volume serial number and its human-chosen volume label (people name drives after themselves, their machine or their employer), any command-line arguments the shortcut passes to its target, and the three FILETIME timestamps for the target's creation, last-access and last-write times captured at the moment the shortcut was made. All of it is parsed in plain JavaScript from the MS-SHLLINK structure - no upload.
This is a selection. The full field manual documents the fields read from each format.
Almost always. The target path and working directory are stored as absolute paths, and on Windows those run through C:\Users\<name>\..., so your account username is written into the shortcut. Sending or sharing a .lnk carries it along.
Yes, when it was created by Windows Explorer. Explorer writes a link-tracking block containing a version-1 UUID, and the node portion of that UUID is the MAC address of the machine that made the shortcut. The scan decodes it. A MAC address identifies one specific network interface, so it ties the file to a physical device.
The tracking block stores two identifiers - a current one and a birth one from when the file was first created. If they differ, the target was moved or copied afterwards. When that happens the scan also recovers the original machine's MAC address and the original creation time from the birth record, so the file's true origin survives the move.
There is no clean in-app strip for shortcuts - the identifying data is structural. The safest fix is to delete the shortcut and recreate it on the machine you are sending from, or just send the target file rather than the shortcut. Note the link-tracking block, target path and volume serial are separate fields, so editing one does not clear the others.
Yes. The shortcut is parsed entirely in your browser with a pure-JavaScript reader; nothing is uploaded. You are only reading the structure that is already inside the file.
File X-Ray reads Windows shortcut files entirely in your browser - the file never leaves your device. For this format you can also download a clean copy with the metadata removed. Scan a file now.