A window manager is the system software that controls the placement, size, stacking order, decoration and focus of application windows on a graphical display. In desktop environments, it is the layer that turns a set of independent drawing surfaces into an arrangement a person can move, resize, minimize and switch between.
The window manager is usually one component of a larger desktop environment, which adds panels, file managers, settings tools and session management. It can also run on its own, which is common on lightweight or highly customized systems. How much the window manager does depends heavily on the display system underneath it, most notably the difference between X11 and Wayland.
How a window manager controls windows
A window manager works by intercepting requests from applications and deciding how each window should actually appear. An application asks for a window of a certain size; the window manager decides where it goes, whether it may take that size, which window sits on top and which one receives keyboard input.
Under X11, the window manager is an ordinary client of the X server that claims a special role through substructure redirection on the root window. The X server then forwards map, move and resize requests to the window manager instead of executing them directly. Under Wayland, there is no separate window manager process: the compositor is the display server, and window management logic lives inside it.
Most window managers perform a recognizable set of duties. The table below lists the core responsibilities and what each one means for the person at the screen.
| Responsibility | What it decides | Visible result |
|---|---|---|
| Placement | Initial position of a new window | Window opens centered, cascaded or tiled |
| Sizing | Width and height within hints and limits | Window respects minimum and maximum sizes |
| Stacking | Which window is drawn above another | Clicked window rises to the front |
| Focus | Which window receives keyboard input | Highlighted title bar, typing goes there |
| Decoration | Title bar, borders and buttons | Close, minimize and maximize controls |
| Workspaces | Which windows belong to which virtual desktop | Separate screens for separate tasks |
Stacking, tiling and dynamic window managers
Window managers fall into three main layout models, and the model shapes the entire working style. A stacking window manager lets windows overlap freely like sheets of paper on a desk. A tiling window manager divides the screen into non-overlapping regions so every visible window uses its share of space. A dynamic window manager switches between layouts on demand.
The choice is less about appearance than about interaction cost. Stacking favors the mouse and suits occasional multitasking, while tiling favors the keyboard and rewards users who keep several terminals, editors and browsers visible at once.
| Model | Window arrangement | Primary input | Best suited to |
|---|---|---|---|
| Stacking | Free overlap, manual positioning | Mouse | General desktop use |
| Tiling | Automatic non-overlapping grid | Keyboard shortcuts | Programming and system work |
| Dynamic | Switchable tiled, floating or monocle | Keyboard and mouse | Users who change tasks often |
| Scrollable tiling | Columns on an endless horizontal strip | Keyboard and touchpad | Wide screens and many windows |
Tiling is not exclusive to dedicated tiling managers. Mainstream desktops now offer snap layouts and edge tiling, which bring part of the tiling benefit to stacking users without a change of workflow.
Window manager, compositor and desktop environment
A window manager, a compositor and a desktop environment are three distinct layers that are often bundled together and therefore often confused. The window manager decides where windows go; the compositor decides how the final image is assembled, including transparency, shadows and animations; the desktop environment supplies the surrounding applications and settings.
| Component | Main job | Relation to the window manager |
|---|---|---|
| Window manager | Geometry, stacking and focus | The subject of this comparison |
| Compositor | Combining window buffers into one frame | Separate on X11, merged with it on Wayland |
| Display server | Talking to input devices and the screen | X server on X11, compositor on Wayland |
| Desktop environment | Panels, launchers, settings and apps | Ships a window manager as one part |
On Windows and macOS the boundaries are internal. Windows uses the Desktop Window Manager, a compositing component that cannot be replaced, and macOS uses its WindowServer process. Third-party tools on both systems can rearrange windows through accessibility or system interfaces, but they extend the built-in manager rather than replacing it.
Choosing and configuring a window manager
Choosing a window manager is a decision about workflow, hardware and maintenance effort. A full desktop environment with its default manager is the right answer for most users, while a standalone manager makes sense when control, speed or a small memory footprint matters more than a ready-made experience.
| Situation | Recommended approach | Reason |
|---|---|---|
| General office desktop | Default manager of the desktop environment | Integrated settings and predictable behavior |
| Older or low-memory hardware | Lightweight standalone stacking manager | Small footprint, often well under 50 MB |
| Development with many terminals | Tiling or dynamic manager | Keyboard control and no wasted space |
| Multiple high-resolution monitors | Wayland compositor with per-output scaling | Correct mixed scaling per screen |
| Kiosk or single-purpose display | Minimal manager or kiosk compositor | One full-screen application, no decorations |
Configuration styles differ widely. Some managers use a plain-text configuration file reloaded at runtime, others are configured in a scripting language, and a few require recompiling the source after every change. Keyboard bindings, workspace rules and per-application rules, such as forcing a video player to float, form the core of most configurations.
Common problems and misconceptions
Most trouble with window managers comes from mismatched expectations between layers. Applications assume certain conventions, and a manager that ignores them produces odd placement, missing decorations or broken full-screen behavior.
- Not every manager composites. On X11 a standalone manager may draw no shadows or transparency unless a separate compositor runs, and screen tearing can appear without one.
- Client-side decorations under Wayland mean some applications draw their own title bars, so the look may differ from window to window.
- Focus models matter. Click-to-focus, focus-follows-mouse and sloppy focus change where typed text goes, which surprises users who switch systems.
- X11 managers do not run on Wayland. Moving to Wayland usually means changing to a compositor that offers a similar layout model.
- Specification support varies. Managers that skip the Extended Window Manager Hints standard can break taskbars, pagers and full-screen games.
A non-technical view
A window manager is the organizer of the screen. Every program draws its own content, but something has to decide where each window sits, how large it is, which one is on top and which one listens to the keyboard. That organizer is the window manager.
Think of a desk covered with papers. Some people pile papers loosely and pull out the one they need, which is how a stacking manager works. Others lay them out side by side in neat rows so nothing is hidden, which is how a tiling manager works. The papers are the same; only the way of arranging them changes.
A concrete example
A backend developer on a Linux laptop connected to a 34-inch ultrawide monitor spends the day in a code editor, two terminals and a browser with documentation. With the default stacking manager, the windows constantly overlap, and switching between them costs repeated mouse movements and Alt+Tab cycles.
The developer switches to a Wayland tiling compositor and defines four workspaces: code, terminals, browser and communication. New terminals split the screen automatically, a single key combination moves a window to another workspace, and a rule makes the video call window float. After a week of adjustment, the developer reports that every relevant window stays visible and most navigation happens without touching the mouse.