DualShock Kalibrierung GUI: Browser DevTools Diagnostic (2026)

DualShock kalibrierung GUI is a query most often typed by someone who already knows about gamepad-tester.com or has heard "open a browser, run the diagnostic". This page goes one layer deeper than the pillar DualShock calibration GUI guide: it shows the developer-side mechanics.

The browser-first approach has three properties that no installer-based tool matches.

First, zero install. The W3C Gamepad API ships with every modern browser. There is no driver, no DS4Windows, no Sony account. The MDN Gamepad API compatibility table confirms Chrome 35+, Firefox 29+, Safari 14.1+, and Edge 79+ all support it.

Second, the API is read-only. You cannot accidentally write a bad calibration value to the controller because the API does not expose a write surface for that operation. The controller's firmware would reject it anyway, but the API not even exposing the option means the diagnostic is provably safe.

Third, every modern browser ships with DevTools that let you call the API directly. You do not need a calibration GUI to use a calibration GUI's underlying data. You can open the console and call navigator.getGamepads() yourself, and you will see exactly what JoyCheck sees.

The procedure differs slightly per browser but the shape is the same. Connect the controller, open a page, open DevTools, expose the controller, query.

Chrome and Edge: connect the DualShock 4 or DualSense via USB-C (DualSense) or Micro-USB (DualShock 4) or pair over Bluetooth. Open any page (it can be about:blank). Press F12 or right-click and choose Inspect. Switch to the Console tab.

Firefox: same connection, same page, but the keyboard shortcut is Ctrl+Shift+K or Cmd+Option+K on macOS, which goes directly to the Console tab.

Safari: enable the Develop menu in Preferences → Advanced. Connect the controller, open a page, Develop → Show Web Inspector (Cmd+Option+I). Switch to the Console tab. Safari is the strictest browser for gamepad access; it sometimes requires a touch gesture rather than a keyboard or mouse gesture to expose the controller.

In every browser, the controller is not visible to JavaScript until a user gesture happens. Press any button on the controller while the focused page is active. The browser registers the gesture and grants the page access to the W3C Gamepad API for the connected controller.

With DevTools open and the controller exposed, type the following into the console:

navigator.getGamepads()

The result is an array. The first non-null entry is your controller. On a typical Chrome session with a single DualSense connected via USB, you will see something like:

GamepadList {
  0: Gamepad {
    id: "DualSense Wireless Controller (Vendor: 054c Product: 0ce6)",
    index: 0,
    connected: true,
    timestamp: 12345.678,
    mapping: "standard",
    axes: [0.012, -0.005, -0.001, 0.007],
    buttons: [GamepadButton, GamepadButton, ...]
  }
}

This is the raw object the W3C Gamepad API exposes. Every field on it is documented in the W3C Gamepad API specification and the MDN Gamepad reference.

The id string tells you the vendor and product IDs. 054c is Sony's USB Implementers Forum vendor ID, registered with USB-IF. 0ce6 is the product ID for DualSense; DualShock 4 uses 09cc (V2) or 05c4 (V1).

The mapping value matters. When mapping is "standard", the browser has recognized the controller and applied the W3C standard layout (face buttons at indices 0-3, shoulders at 4-5, triggers at 6-7, D-pad at 12-15, etc.). When mapping is "" (empty string), the browser has not mapped the controller and the button indices may be in an arbitrary controller-native order.

The axes array is the calibration GUI's primary signal. Each value is a normalized float from the W3C Gamepad API in the range -1.000 to 1.000.

For DualShock 4 and DualSense, the standard mapping is:

axes[0] = left stick X  (left -1.0, right +1.0)
axes[1] = left stick Y  (up -1.0, down +1.0)
axes[2] = right stick X
axes[3] = right stick Y

A single call to navigator.getGamepads()[0].axes gives you one snapshot. To get a continuous readout, run a small requestAnimationFrame loop:

function readGamepad() {
  const gp = navigator.getGamepads()[0];
  if (gp) {
    console.log(gp.axes.map(a => a.toFixed(3)).join(', '));
  }
  requestAnimationFrame(readGamepad);
}
readGamepad();

Five lines of JavaScript. Pasted into DevTools console, this prints the four stick values every render frame (60 Hz on a 60 Hz display, 120 Hz on a 120 Hz display). Stop it by closing the tab or refreshing the page.

For the drift test: leave the controller untouched on a flat surface for five seconds. Watch the values. A healthy stick reports under ±0.005 at rest when new. A worn stick reports above ±0.030. The threshold most stick-module replacement guides cite is ±0.10, beyond which game-side default deadzones cannot hide the drift.

The buttons array is structured differently. Each entry is a GamepadButton object with two readable properties: pressed (boolean) and value (float 0.0 to 1.0). For digital buttons, value is binary; for analog triggers, value reports the press depth.

The W3C standard mapping for DualShock 4 and DualSense:

To check a specific button in the console:

navigator.getGamepads()[0].buttons[6].value

That gives you the L2 trigger pressure as a 0.0-1.0 float. Press the trigger, run the query again, watch the value climb. A healthy L2 sits at 0.000 fully released and 1.000 fully pressed. A worn trigger may floor at 0.020 (sensor wear) or top out at 0.940 (potentiometer wear in the trigger module).

For a complete browser-DevTools diagnostic, this is the minimal code:

const out = document.createElement('pre');
out.style.cssText = 'position:fixed;top:10px;right:10px;background:#000;color:#0f0;padding:8px;font-family:monospace;z-index:9999';
document.body.appendChild(out);

function tick() {
  const gp = navigator.getGamepads()[0];
  if (gp) {
    const axes = gp.axes.map(a => a.toFixed(3)).join(' ');
    const triggers = [gp.buttons[6].value.toFixed(3), gp.buttons[7].value.toFixed(3)].join(' ');
    out.textContent = `axes: ${axes}\nL2/R2: ${triggers}`;
  }
  requestAnimationFrame(tick);
}
tick();

Paste this into the DevTools console on any page after the controller is exposed. A small overlay appears in the top-right showing the four stick axes and the two trigger values, updating every frame.

This is, in essence, what JoyCheck does, dressed up with proper UI, additional sections for buttons and D-pad, drift threshold colour coding, idle test timing, and a clean copy-to-clipboard for the diagnostic readout. The underlying API call is identical.

There are installer-based tools for DualShock diagnostics. DS4Windows is the most common; the Sony PlayStation support library lists none officially, but third-party tools exist. The browser-based approach has clear advantages.

No installer trust required. DS4Windows is open-source and well-regarded, but installing any executable is a trust decision. A browser-based tool runs in the same sandbox as every other web page; it cannot access your filesystem, read other tabs, or write to your registry.

Works on every OS. The W3C Gamepad API is implemented in browsers, which run on Windows, macOS, Linux, ChromeOS, iOS, and Android. The same diagnostic page works everywhere. DS4Windows is Windows-only.

No system updates lag. When Chrome ships an update, it ships everywhere within a week. Sony controller support, Bluetooth quirks, and HID protocol changes are all addressed by the browser without you doing anything. An installer-based tool depends on its maintainer keeping pace.

Zero residue. Close the browser tab and nothing remains. No installed software, no registry entries, no service running in the background.

The BT SIG specification governs the underlying Bluetooth transport layer; the W3C Gamepad API sits one layer up and provides a uniform JavaScript surface regardless of whether the controller is connected over USB or BT.

If you can do the diagnostic in 12 lines of JavaScript in the DevTools console, why would anyone use JoyCheck?

For developers debugging a specific symptom, the console may be the faster path. You know what you are looking for, you write the loop, you read the value. The whole exercise takes under a minute.

For everyone else, a tool with a UI is worth the conversion. JoyCheck and similar tools add things the bare API does not provide:

• Threshold colour coding. Values above ±0.030 turn yellow, above ±0.10 turn red. You see drift severity without reading numbers.
• Idle drift timer. The 5-second idle test happens automatically when no input changes; you do not have to time it yourself.
• Per-button history. The tool tracks which buttons you have pressed in the current session and flags any that have not responded.
• Trigger graph. The L2 and R2 pressure history shows you whether the trigger curve is smooth or jittery, not just whether floor and ceiling are correct.
• Vibration test. The Gamepad API exposes a vibration write interface; JoyCheck wraps it with preset patterns to verify the haptic motors are physically running.

For the use cases where you want a clean read of "is this controller healthy", the wrapped tool is faster. For the use cases where you want to know exactly what the W3C Gamepad API reports for a specific button index at a specific time, the DevTools console is your friend.

If you want the polished UI, open JoyCheck. If you want the raw API, open DevTools and paste the 12-line snippet from the snippet section above. Both give you the same underlying W3C Gamepad API readings.

For the technical model, see the DualShock calibration GUI pillar and the calibration math article. The Sony documentation gap article covers what Sony's official support library says.

For step-by-step action flows, the seven-step browser walkthrough is the practical companion. Related deep dives: stick drift explained, PS4 controller calibration walkthrough, DualSense calibration, and the game controller PC test hub.

1. W3C, "Gamepad API specification": www.w3.org/TR/gamepad
2. Mozilla Developer Network, "Gamepad API reference": developer.mozilla.org/en-US/docs/Web/API/Gamepad_API
3. Mozilla Developer Network, "Using the Gamepad API": developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API
4. USB Implementers Forum, "HID information": www.usb.org/hid