How to Allow WSL to Open Your Browser: A Complete Guide

When you're running commands inside Windows Subsystem for Linux (WSL) — whether launching a local dev server, clicking a URL in terminal output, or running a script that calls xdg-open — you've probably noticed that nothing happens. No browser opens. The URL just sits there. This is one of the most common friction points for developers using WSL as their primary Linux environment on Windows.

Here's why it happens, and how to fix it.

Why WSL Doesn't Open a Browser by Default

WSL runs a genuine Linux kernel inside Windows, but it doesn't have a graphical desktop environment. When a Linux program tries to open a URL, it typically calls xdg-open, which relies on a display server (like X11 or Wayland) to launch a GUI app. Inside a standard WSL terminal session, no display server is configured — so the command fails silently or throws an error.

This is a layer mismatch problem: the Linux environment doesn't automatically know how to hand off a browser request to the Windows side of the machine, even though Windows browsers are right there.

The good news is that WSL is tightly integrated with Windows, and there are clean ways to bridge that gap.

Method 1: Point xdg-open to a Windows Browser Executable 🖥️

The most straightforward approach is to override what xdg-open does by creating a shell script or alias that calls your Windows browser directly through WSL's interop layer.

WSL can execute Windows .exe files natively. That means you can call something like:

/mnt/c/Program Files/Google/Chrome/Application/chrome.exe 

directly from a WSL terminal. To make this seamless, create a wrapper script:

1. Create a file at /usr/local/bin/xdg-open (or /usr/bin/xdg-open if overriding the existing one):

#!/bin/bash /mnt/c/Program Files/Google/Chrome/Application/chrome.exe "$@" 

2. Make it executable:

sudo chmod +x /usr/local/bin/xdg-open 

Now when anything inside WSL calls xdg-open https://example.com, it passes the URL to Chrome on the Windows side. Adjust the path to point to whichever browser is installed — Edge, Firefox, or Brave all work the same way.

Method 2: Use the wslview Utility from wslu

wslu is a collection of utilities specifically designed for WSL interoperability. The wslview command acts as a drop-in replacement for xdg-open and automatically opens URLs and files using the appropriate Windows default application — including your default browser.

Install it with:

sudo apt install wslu 

Then either use wslview directly, or symlink it:

sudo ln -sf $(which wslview) /usr/local/bin/xdg-open 

After this, xdg-open system-wide in WSL will defer to your Windows default browser, not a hardcoded path. This is a more portable solution — if you change your default browser in Windows Settings, WSL follows automatically.

Method 3: Set the BROWSER Environment Variable

Some applications — particularly Node.js tools, Python dev servers, and frameworks like React or Vite — check the BROWSER environment variable rather than calling xdg-open. You can set this in your shell configuration file (~/.bashrc, ~/.zshrc, etc.):

export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe" 

Or, if you've installed wslu:

export BROWSER=wslview 

This tells development servers like Vite's --open flag or create-react-app exactly which command to call when they try to launch a browser automatically.

Method 4: WSL 2 with WSLg (GUI App Support)

If you're on WSL 2 with a recent version of Windows 11 (and some Windows 10 builds), Microsoft's WSLg feature provides full GUI support. With WSLg enabled, you can actually install and run Linux-native graphical apps — including browsers like Firefox for Linux — directly from WSL, with windows appearing on your Windows desktop.

This is a fundamentally different approach: instead of routing through Windows executables, you're running a real Linux browser with GPU-accelerated rendering via the built-in Wayland/X11 bridge.

Key Variables That Affect Which Method Works for You

Not every approach works equally well across all setups. A few factors determine which path makes sense:

• WSL version (WSL 1 vs WSL 2): WSLg only works on WSL 2. The wrapper and wslu methods work on both.
• Windows version: WSLg requires Windows 11 (build 22000+) or a specific Windows 10 Insider build.
• Which browser is installed: The hardcoded .exe path approach requires you to know the exact installation path, which varies between Chrome, Edge, Firefox, and others.
• What's triggering the browser open: Dev servers check BROWSER; scripts call xdg-open; some tools do both. Knowing which mechanism your toolchain uses changes which fix actually solves the problem.
• Shell environment: If you use Zsh, Fish, or a custom shell, make sure environment variable exports go in the right config file.

When the Fix Works but the URL Doesn't Load

One edge case worth knowing: sometimes the browser opens but shows a localhost address that doesn't resolve. This happens because WSL 2 runs in a lightweight virtual machine with its own network interface, meaning localhost inside WSL isn't always the same as localhost on Windows. 🔧

If your dev server starts on port 3000 inside WSL 2, the correct Windows URL may be http://127.0.0.1:3000 — and modern WSL 2 builds handle this automatically with localhost forwarding. Older builds may require checking the WSL IP with hostname -I and using that address instead.

The right combination of methods depends on your WSL version, Windows build, browser preference, and the specific tools in your development workflow — which means the ideal setup looks a little different for everyone.