How to Access Files Between Windows and WSL Correctly

Moving files between Windows and WSL works in both directions, but through different mechanisms — understanding the underlying bridge helps you use both correctly rather than fighting unexpected performance or permission behavior.

Step 1: access Windows drives from inside WSL

cd /mnt/c/Users/YourName/Documents
ls /mnt/c

Every Windows drive letter is mounted under /mnt/ inside WSL — /mnt/c for your C: drive, /mnt/d for D:, and so on.

Step 2: access WSL’s Linux filesystem from Windows

File Explorer address bar:
\\wsl$\Ubuntu\home\yourusername\

Or, on newer WSL versions:

\\wsl.localhost\Ubuntu\home\yourusername\

Windows treats your WSL distro’s filesystem as a network location, browsable directly through File Explorer or any Windows application’s file-open dialog.

Step 3: open the current Linux directory in File Explorer directly

explorer.exe .

Run from inside a WSL shell, this opens Windows Explorer directly at your current Linux working directory — genuinely convenient for switching to GUI file management mid-task.

Step 4: open the current Windows-accessible directory from an actual Windows path in WSL

cd "$(wslpath 'C:\Users\YourName\Documents')"

wslpath converts a Windows-style path into the equivalent WSL path, useful when you have a Windows path (copied from Explorer, for instance) and need the WSL-side equivalent.

Step 5: decide where a given project’s files should actually live

Working primarily from Linux-side tools (a Node.js
  or Python project you build and run from WSL)?
  → keep it on the Linux-native filesystem (~/projects/)

Working primarily from Windows-side tools, only
  occasionally touching it from WSL?
  → /mnt/c is fine

This isn’t an arbitrary preference — cross-filesystem access through the 9P bridge carries real per-operation overhead, which compounds significantly for workloads doing many small file operations.

Step 6: copy files between the two filesystems when needed

cp -r /mnt/c/Users/YourName/project ~/project
cp -r ~/project /mnt/c/Users/YourName/project-backup

Copying, rather than only ever accessing files in place, is the right move whenever you’re about to do sustained, intensive work on a project currently living on the “wrong” filesystem for your primary tooling.

Step 7: understand case sensitivity differences

Linux filesystems are case-sensitive; NTFS (Windows’ filesystem) is not by default — a project relying on case-sensitive filenames can behave unexpectedly if kept under /mnt/c and touched by tools on both sides, since NTFS won’t distinguish File.txt from file.txt the way ext4 does.

Step 8: verify performance-sensitive work is actually on the right filesystem

time cp -r some-large-directory /tmp/test-copy

If a routine file operation feels unexpectedly slow, checking whether you’re working against /mnt/c when you should be Linux-native is the first, most common explanation worth ruling out.

Why understanding both access directions matters, not just one

Most WSL guidance focuses on accessing Windows files from Linux, since that’s the more commonly needed direction — but knowing the \\wsl$\ (or \\wsl.localhost\) path for the reverse direction, and explorer.exe . as a shortcut, rounds out genuinely comfortable day-to-day use of both environments together.