DualSense Tester: checking a PlayStation controller in the browser

The problem: a controller fault is hard to see through a game

DualSense Tester is a web page for testing a DualSense, a DualSense Edge or a DualShock 4, and the reason it exists is that a game is a bad diagnostic instrument for a broken button.

When a controller misbehaves in a game, the symptom is indirect. A drifting stick, a dead trigger or a motor that has gone quiet all present as a gameplay problem rather than as a hardware fault, and the usual path is to try the controller on another console, another port or another OS before suspecting the device. That path is slow and, in the middle of it, you cannot see the raw input.

The tool answers with a surface where every element of the controller is visible at once. The feature list is a bill of materials for a DualSense: read controller factory information, test all buttons and axes, test the touchpad, test the gyroscope and accelerometer, test the vibration motors, test the lights, test the adaptive triggers, and support for multiple controllers at the same time.

The factory information item is the one that is easy to overlook and is often the most useful. A DualSense carries its own identifiers, and being able to read them tells you what the controller believes it is, which matters when a device is being resold, flashed or paired with a console that rejects it.

So the value is not that the tool diagnoses faults. It does not claim to. The value is that it makes the controller's state legible, and leaves the interpretation to the person holding it.

WebHID is the whole trick, and the same trick is why Linux sometimes fails

The mechanism is the browser's WebHID API, and choosing it is the design decision that makes the tool a web page rather than an application.

The developer dependencies include the TypeScript types for w3c-web-hid, and the tool runs against the controller through that interface. There is no native bridge, no driver, no companion service and no account. The page asks the browser for a device, the user picks the controller from a browser-level chooser, and the input events and output reports go over HID.

That gives you the two properties the project advertises. It runs on any platform where the browser exposes WebHID, so the same page covers Windows, Mac and Linux without a build per OS. And the page can write to the device as well as read from it, which is what the vibration, light and adaptive trigger tests need.

The cost of that choice shows up in the project's own FAQ, and the failure mode is specific. On a Linux distribution, the page can go blank after the controller is selected, and the answer given is a lack of permissions for the hidraw device, with the project pointing at issue 76 for the resolution. The hidraw device is the kernel's raw HID interface, and on Linux a browser talking to it needs permission that a desktop Linux user does not always have by default.

So the tool is genuinely install-free on the platforms where WebHID is available, and genuinely permission-dependent on Linux, where a udev rule is the usual fix. The FAQ entry is one of the more useful pieces of documentation in the repository, and it exists because the failure is confusing: a blank page gives no hint that a permissions problem is the cause.

DualSense Edge is the differentiated part, and its limits are stated in the feature list

Most of the feature list is a straightforward hardware checklist, and it applies to any of the three supported controllers. The interesting part is the Edge.

For the DualSense Edge you can customize profiles in the browser using this tool. The feature list spells out the support matrix with a precision that is worth reading in full: DualSense Edge Basic Support, DualSense Edge Full Support, DualSense Edge Profile Customization, DualShock 4 Support, and Multiple Controllers Support.

A controller profile is a stored configuration, and on the Edge it covers whatever the console lets you set per profile. Being able to edit that from a browser rather than only from a console or a PC application is a genuine convenience for anyone who has more than one profile and does not want to sit on a console to change it.

The list also contains the project's own unfinished work, written in capitals: TODO, DualSense Edge button remapping. So the Edge coverage is not complete in the sense that matters to a remapper. You can set up profiles, and the mapping of a button to something other than its factory function is not done. A user whose problem is that one button misfires will find a tester, not a remapper.

The three controllers are also not equivalent. A DualShock 4 lacks adaptive triggers, so part of the test surface is inherently empty for it, and the README grants it plain support rather than the fuller treatment the Edge gets.

Running it yourself: Bun, Vite, and a dev build of the same page

The hosted site is at ds.daidr.me, and the repository is a Vue application built with Vite and managed with Bun. The setup is two commands:

bun i

The second command starts the development server with hot reload:

bun run --bun dev

And the production path type-checks, compiles and minifies in one step:

bun run --bun build

The package.json shows the shape of the project more clearly than the documentation does. The dev script runs vite with the host flag, so the dev server is reachable from another machine on the network, which matters here because a controller is usually plugged into a different machine than the one running the editor. The build script is bunx --bun vite build, the preview script is vite preview, and the test script runs Vitest through node with a threads pool. Type checking is a separate vue-tsc invocation against tsconfig.app.json, and linting runs oxlint and then eslint, both with the fix flag, with a lint:migrate script that runs the oxlint migration tool against the eslint configuration.

The dependency list shows the two libraries that matter for what the page does. pixi.js at version 8 is the renderer, which is how a browser can draw a live representation of controller state at interactive rates, and vue-i18n at version 11 is the translation layer, wired through the unplugin-vue-i18n build plugin. Pinia handles state, UnoCSS handles styling, and a workspace package called fancy-controller is the internal controller abstraction, with a build:icon script that builds it separately. The repository also carries a Vite config for an installable web app, vite.config.iwa.ts, and a Vercel config for deployment, alongside a.dockerignore file.

Translated by contributors, and the project asks for help in one specific place

The translation story is unusually thorough for a small tool, and it is worth reading because it says how the project is organised.

The interface is translated through Crowdin, and the repository carries a crowdin.yml configuration. The contributor list in the documentation shows the scale: the main maintainer alone has contributed 3,602 words across Arabic, Arabic Egypt, Simplified Chinese, French, German, Greek, Italian, Persian, Brazilian Portuguese, Russian, Turkish and Ukrainian, and the list continues with contributors in the several-hundred to one-thousand word range covering Bengali, Spanish, and more.

A dozen or more languages for a page that is mostly buttons and axis labels is a reasonable target, since the people who most need a controller test are often the people who cannot read the diagnostic text in the language they think in.

The contribution guidance is narrow and specific. If you want to add a new language or improve an existing one, the project points at issue 14 for the details, which is the standard way to route translation work through Crowdin rather than as direct pull requests. The sponsors section is a separate image, and the rest of the repository tree shows the usual working files, an .oxlintrc.json configuration, a config/ directory, a design/ directory, dev/ and prod/ directories, a plugins/ directory, a public/ directory, src/, tests/, and separate TypeScript configurations for the app and the node side.

One repository entry is a hint about how the project is built: a .trae/ directory, alongside a .vscode/ directory and an .editorconfig. Two editor configurations in one repository is a small sign that more than one person's toolchain touches the code.

Where DualSense Tester is the wrong tool

The first limit is that WebHID support is a browser-level matter, and it is not universal. A browser without the API, or a platform policy that blocks it, means the tool cannot run at all, and there is no fallback to a native application in this project. On Linux there is an additional permission hurdle around the hidraw device, and the FAQ sends you to an issue thread rather than to a script, which tells you the fix is distribution-specific.

The second is that this is a manual instrument, not a test suite. You press a button and you look at the screen. There is no scripting layer, no assertion, no way to run a pass and fail list over a device. The repository has Vitest and a test script, but the tests are for the application code, not for driving a controller through a battery of checks. A manufacturer or a refurbisher who wants to certify a hundred units a day needs something else entirely.

The third is the Edge remapping gap, already mentioned. The tool edits profiles but does not remap buttons, and the feature list marks that as unfinished work rather than a plan with a date. The other controller families are less capable than the Edge by physics, so a DualShock 4 owner gets a subset of the surface.

The fourth is that there is no released version to point at. The repository has no GitHub releases, the last push to the repository was on 2026-10-22, and the package.json marks the project as private, so the site at ds.daidr.me is the deliverable. For a page that people use to check a device, that is fine. For anyone who wants to host their own copy and keep it, they are running from a moving branch.

The fifth is the licensing of the controller itself. The tool is MIT licensed, and the projects it reads, PlayStation hardware and DualSense Edge profiles, are governed by the console maker's terms rather than by anything in this repository. Nothing in the documentation offers a view on that, and the profile editing feature is the part most likely to sit close to that line, so anyone using it commercially should check the platform terms rather than infer them from the open licence of the page.

Editorial conclusion

DualSense Tester is worth bookmarking if you own a PlayStation controller and want to know whether a button, an axis, a motor or the adaptive triggers have actually failed, because it runs over the browser's WebHID interface with no driver, no install and no setup, because it covers the parts of a controller that a game would only exercise in passing, such as the factory information, the touchpad and the motion sensors, and because the DualSense Edge profile editing happens in the same page. It is the wrong tool if your operating system blocks WebHID, and it is the wrong tool if you need a scripted test suite rather than a manual check. Before you rely on it, check three things: that your browser exposes the WebHID API and that your platform permits it, since on Linux the documentation points at a hidraw permission problem that leaves the page blank after the controller is selected; that the project has no GitHub releases, with the last push on 2026-10-22, so the site at ds.daidr.me is what you get rather than a version you can pin; and that button remapping is still listed as a TODO in the feature list, so the Edge profile editing is the only customisation on offer.

Frequently asked questions

Official sources

1. daidr/dualsense-tester on GitHub
2. Issues
3. License: MIT
4. Project website
5. README