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: