An executable is one of the richest metadata targets there is - it is a compiled program, and compilation leaves fingerprints. A single .exe, .dll, .so or .dylib can carry the developer's build-machine path and username, the certificate that signed it, the exact toolchain that built it, and hardcoded URLs and repository details. This scan reads all of it in your browser, without the file leaving your device.
Scan a Executable fileA compiled program is not anonymous. When a Windows .exe or .dll was built with debug information it keeps the absolute path to its symbol database (the PDB path), which almost always looks like C:\Users\<name>\source\... and hands over the developer's account username, the internal project name and the drive layout. If the file is code-signed, the scan reads the name and organisation off the certificate's leaf - the real publisher, not the certificate authority that vouched for them.
Windows binaries also carry an undocumented Rich header that Microsoft's linker stamps in, which pins the exact Visual Studio compiler and linker build on the developer's machine, plus a version resource holding CompanyName, the original filename the binary was built as, and free-text Comments or Author fields where developers leave notes. The link timestamp records the wall-clock time the file was linked, unless the build was made reproducible, in which case the field is flagged as unreliable.
The same scan handles Linux .so and ELF binaries and macOS .dylib Mach-O binaries. A Go binary embeds its module path - very often github.com/<user>/<repo> - and the exact git commit it was built from; an ELF's .comment string leaks the compiler and, on Debian and Ubuntu, the distro release; a Mach-O carries a unique build UUID and, in its RPATH, the developer's DerivedData build path. Packers, high-entropy (encrypted) code sections, the imported libraries and demangled C++ class names are surfaced too.
This is a selection. The full field manual documents the fields read from each format.
Far more than a document. A compiled binary can hold the developer's build-machine path and account username (from the debug/PDB path), the code-signing certificate and the real publisher on it, the exact compiler and linker version, a link timestamp, the libraries it imports, and - for Go or Mach-O binaries - the source repository, git commit or build UUID.
Often, yes. If the program was built with debug info, its PDB path usually looks like C:\Users\<name>\source\... and exposes the account username and project layout. Signed binaries additionally name the publishing person or organisation on the certificate, and version-resource Author, Company and Comments fields can carry names directly.
No. It reads the signer's identity, organisation, certificate serial and validity window off the certificate, but it does not cryptographically verify the signature chain, so treat the named signer as self-asserted until you verify it separately.
Yes. The same scan reads Windows PE (.exe/.dll), Linux ELF (.so) and macOS Mach-O (.dylib) binaries, plus Unix .a static libraries, each with the fields native to its format.
File X-Ray reports what's inside but does not strip it, and much of it (imports, toolchain, signature) is structural. Removing the identifying parts means rebuilding: strip debug symbols and the PDB path, use a deterministic build to neutralise the timestamp, and drop unneeded version-resource strings before signing.
File X-Ray reads Executable files entirely in your browser - the file never leaves your device. This format is inspected, not modified. Scan a file now.