hodgef/simple-keyboard: a JavaScript on-screen keyboard you wire into your own UI

The problem simple-keyboard solves, and who is actually asking for it

A browser page normally hands text entry to the operating system. On a desktop that is fine. On a kiosk, a point-of-sale terminal, a museum display or a locked-down touch screen, it is not: the OS keyboard may be disabled, may cover half the screen, may not exist at all, or may let the user reach parts of the system you did not intend to expose. simple-keyboard draws the keyboard inside your own page instead, as a component you place and style yourself. The README describes it as a "Virtual Keyboard for Javascript" compatible with JS, React, Angular or Vue projects, and the package keywords list kiosk, osk, onscreen and touchscreen, which is a fair summary of the intended audience. If you are a web developer shipping an interface where you own the input surface, this is the category of tool you are looking for. If you are an end user searching for something to replace the keyboard on your phone, you are in the wrong place: the repository is a JavaScript library published to npm, not an installable Android or iOS app.

What you get in the box, and what the repository layout tells you

The package is published as simple-keyboard with main pointing at build/index.js, and the build script runs webpack three times: a default bundle, a modern bundle via webpack.config.modern.js, and a modern ESM bundle via webpack.config.modern_esm.js, followed by tsc for type declarations. That layout matters when you pick an import path. The README notes that if you do not want to support old browsers you can use the Modern Browsers bundle at build/index.modern.js, which implies the default output carries the compatibility weight. The stated compatibility list is broad: Internet Explorer 11, Edge (Spartan) 16+, Edge Chromium 79+, Chrome 49+, Safari 9+, Firefox 57+ and iOS 9+. Supporting IE11 in 2026 is a deliberate choice, and it is the kind of choice that costs bundle size and build complexity for everyone who does not need it. The modern bundles are the escape hatch, and the fact that they exist as separate webpack configs rather than a build flag suggests the maintainer expects both audiences to keep existing. The source lives in src/ with TypeScript configuration at the top level, so types are generated rather than hand-written.

Installing simple-keyboard and rendering a first keyboard

The README says you can use simple-keyboard as a script tag from a CDN or install it from npm, and points to the Getting Started page for details. The npm route is the one the repository itself uses for its demo. Install the package, then follow the demo instructions the README gives, which are to clone the repository, run npm install, run npm start, and visit http://localhost:3000/. Those are the only commands the README states for running the project locally.

npm install
npm start

After npm start, the README says to visit http://localhost:3000/ to see the demo. That demo is the fastest way to see which layouts and options are available before reading the full documentation site, which the README links as the reference for usage beyond the demo. The README does not reproduce a constructor example inline, so the Getting Started and documentation pages are where the actual mounting code lives.

Extending it: modules, and where the core library stops

The core library draws keys and reports input. Anything beyond that is a module. The README lists Autocorrect, Input Mask, Key Navigation and Swipe Keyboard as available modules and links to a Modules page for writing your own. That split is honest about scope: autocorrect and input masking are genuinely separate concerns from rendering, and bundling them by default would penalise users who do not want them. The trade-off is that a project needing autocorrect is really adopting two things, and the module's own maintenance and version compatibility become your problem. The README also links a Community Libraries & Integrations wiki page, which is worth reading before you write an integration from scratch, though community code carries no maintenance guarantee from the maintainer. If your requirement is a plain keyboard with custom layouts and key handlers, the core is enough. If it is predictive text or gesture typing, budget for the module layer.

The limitation that decides most evaluations

simple-keyboard renders a keyboard. It does not make text entry secure, and it does not replace the need to handle input validation, focus management or accessibility yourself. The README does not document accessibility behaviour such as screen reader support or ARIA roles, and it does not document security properties, so neither should be assumed from the project's existence. There is a second, more practical boundary: the README's compatibility list reaches back to Internet Explorer 11 and iOS 9, which means the default bundle is built for browsers most projects no longer target. You can take the modern bundle, but then you are on a build path the README mentions only in a single note. The third limitation is the one that catches people who arrive from search: this is a web component. There is no APK, no Android app and no iOS app in the repository, and the README does not describe one. If your requirement is a system-level keyboard replacement on a phone, this project does not address it, and the searches that lead people here for that reason are looking for something else.

Where it sits next to native and framework input components

The obvious alternative is the browser's own input handling: an <input> element plus whatever keyboard the operating system provides. That approach costs nothing, works with assistive technology by default, and handles every locale the OS supports. It fails precisely in the environments simple-keyboard targets, where the OS keyboard is unavailable, unwanted, or controllable by the user in ways you cannot allow. A second alternative is a framework-specific input component, but the project already covers that ground: the README points to a React package at hodgef/react-simple-keyboard and shows Angular and Vue in the demo showcase, so the framework wrappers exist alongside the core rather than competing with it. The real decision is not which virtual keyboard library to pick but whether you need an in-page keyboard at all. If the OS keyboard is acceptable, it is almost always the better answer, because it brings locale coverage and accessibility for free. simple-keyboard earns its place when that assumption breaks.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-25, so the project is being touched. The release history tells a different story about stability: 3.8.0 shipped on 2024-09-12, 3.7.0 on 2023-08-21 and 3.6.0 on 2023-05-26, which is roughly one minor release a year. The package.json version, 3.8.192, shows frequent patch-level publishes between those minors. Practically, that means you should expect a stable API with occasional fixes, and you should not expect rapid feature movement. Upgrading is a webpack and Babel rebuild on the maintainer's side, and for consumers it is an npm version bump; the risk sits in the three separate bundles, because a change to the build configuration can affect the modern and ESM outputs differently from the default one. On licensing, the project is MIT, which the README states and the LICENSE file confirms. MIT permits commercial use and modification, but it also means the code comes with no warranty, so the compatibility claims in the README are the maintainer's statement rather than a guarantee you can rely on without testing. This is not legal advice; check the licence text yourself if your organisation has requirements.

Editorial conclusion

Adopt simple-keyboard if you are building a web UI where the operating system keyboard cannot appear or cannot be trusted, such as a kiosk, a POS terminal or a touch screen running in a browser. Do not adopt it if what you actually want is a replacement keyboard app for Android or iOS; this is a JavaScript component that renders inside a page, and the repository does not describe a mobile app or an APK. Before committing, verify your target browsers against the compatibility list in the README, since the default bundle supports Internet Explorer 11 and Chrome 49 while a separate Modern Browsers bundle exists at build/index.modern.js for projects that do not need those, and confirm that the input handling you need is covered by the core library or by one of the listed modules rather than assumed.

Frequently asked questions

Official sources

1. hodgef/simple-keyboard on GitHub
2. License: MIT
3. Project website
4. README
5. Releases