Debugging Input Streams with the Input Debugger

Utilize Unity’s built-in Input Debugger to monitor active devices and verify that input signals reach the application correctly.

In this lesson, you will learn how to use the Unity Input Debugger to verify that your hardware signals are correctly reaching your game, ensuring your Input Actions are actually receiving data.

Why Use the Input Debugger?

When you’re building player movement or interaction systems, sometimes you press a button and… nothing happens. Is the code broken? Is the Input Action mapped incorrectly? Or is the controller itself not communicating with Unity? The Input Debugger acts as a "stethoscope" for your game’s input stream, allowing you to see exactly what Unity sees from your connected devices.

Accessing the Debugger

To open this tool, navigate to Window > Analysis > Input Debugger. This window lists all active devices—like your keyboard, mouse, or gamepads—currently recognized by the engine.

Identifying Input Signals

When you click on a device in the left-hand pane (e.g., "Keyboard" or "XInput Controller"), you will see a list of every control on that device in the right-hand pane. This is the "Input Stream" in its raw form.

Monitor Activity: If you press a key or move a joystick, the corresponding entry in the list will highlight or show changing values in the "Value" column in real-time.
Verify Connections: If you press a button on your controller and the value in the Debugger doesn't change, you know the issue is with the hardware connection or the driver, not your C# script.
Debug Input Action Maps: If the hardware works in the Debugger but your InputAction callbacks (which you learned to implement in Lesson 22) aren't firing, you can isolate the problem. It proves the hardware is sending a signal, which means the issue lies in your Input Action Asset configuration (Lesson 19) or your action mapping (Lesson 20).

Think of this tool as the ultimate "source of truth." By checking the Input Debugger first, you can instantly confirm if your controller is talking to Unity before you start digging through your physics logic or script callbacks. It saves you from debugging perfectly functional code when the actual problem is a disconnected device.

Key Takeaway: The Input Debugger is your first line of defense; if the signal appears here but not in your game, the issue is with your Input Action mapping; if it doesn't appear here, the issue is with your hardware or drivers.