Run custom JavaScript with a keyboard shortcut in Chrome

Bind your own JavaScript to a key and run it against the live page with full context — url, title, selection, and more. No extension build required.

To run custom JavaScript with a keyboard shortcut in Chrome, write your function in an extension that binds it to a key and executes it in the active tab. With HotKeyNavigator you type plain JavaScript into a built-in editor, bind a key, and it runs against the live page — no build step, no packaging, no reloading the extension.

Shortcuts, text templates, and click macros cover most browser automation without a line of code. But when a task needs real logic — read three fields, do some math, rewrite part of the page — you want your own script on a key. This guide covers the ways to do it, how to bind your first function, and what context your code gets.

Ways to run JavaScript on a keypress

There are three common ways to trigger JavaScript from a keyboard shortcut in Chrome, and they differ mostly in setup cost. The browser’s own commands API needs a packaged extension and a reload each edit; a bookmarklet runs code but only on a click; a dedicated runner lets you edit and fire a script from a key with no build cycle.

ApproachSetupEdit-and-run loopGets page context
Chrome commands APIBuild + load an extensionSlow — repackage each changeManual wiring
Bookmarklet on a keyPaste code into a bookmarkManual — no real editorYes, on click
Dedicated JS runnerNone — built-in editorInstant — save and firePassed in for you

If you are shipping an extension to other people, the commands API is the right tool. If you just want your own logic behind a key on the sites you use, a runner removes the whole build-and-reload cycle and gets you straight to the code.

Bind your first JavaScript shortcut

You bind a JavaScript shortcut in four steps: open the editor, write plain JavaScript, assign a trigger key, and save. The function is live on the next page you visit — no reload, no repackage — and you can edit it any time and it takes effect immediately.

  1. Open the built-in JavaScript editor from the command palette.
  2. Write plain JavaScript — no wrapper, no boilerplate required.
  3. Bind it to a trigger key and, if you want, scope it to certain sites.
  4. Save and press the key on a page to run it against the live DOM.

What context your function receives

Your function runs in the page context, so it can query and mutate the DOM exactly like a userscript — the same model as a browser extension’s content scripts, which execute in the context of web pages. It also receives the values you usually need up front — the current url and title, any selectedText, and the activeElement — so you skip the boilerplate of grabbing them yourself and go straight to the logic.

Read the page

Pull values off the DOM, read the user’s current selection, or inspect the focused field. Because you get selectedText and activeElement passed in, a script that acts on “whatever I have highlighted” is a few lines, not a scavenger hunt through the DOM.

Change the page

Rewrite text, fill fields, toggle classes, or inject a small UI. Edits go through the browser’s native path, so the host app and frameworks like React and Vue stay in sync rather than getting out of step.

Chain it with other steps

A JavaScript step can be one link in a longer multi-step sequence — navigate, wait for the page, click, fill, then run your script. That lets code handle only the part that needs logic while the no-code steps do the rest, so you script the hard 10% and leave the rest to click macros.

Practical scripts to start with

The best first scripts automate a small, exact task you repeat by hand. These are short, run in the page context, and pay back instantly.

  • Reformat the selected text — trim, title-case, or strip tracking parameters from a copied URL.
  • Read three fields off a record and drop a combined string into your clipboard.
  • Toggle a distraction — hide a sidebar or expand every collapsed comment.
  • Extract a value from the page and open a deep link built from it.

When to reach for a script — and when not to

Reach for JavaScript only when a task needs logic the no-code actions cannot express: reading several values and combining them, doing math, or transforming text with rules. For everything else — inserting text, clicking a fixed flow, jumping to a page — a template or macro is faster to build and easier to maintain than code.

A good rule is to start no-code and drop to a script at the exact point you hit a wall. If you find yourself wanting an "if this value, then that" or a calculation, that is the moment for a JavaScript step. If you are just repeating clicks or typing, you are still in macro and snippet territory, and staying there keeps the workflow readable for the next person — or the future you who forgot how it worked.

Three patterns that cover most scripts

Most useful page scripts fall into one of three shapes. Recognising which one you need turns a vague "I want to automate this" into a function you can actually write, because each pattern has a clear starting point in the context your function already receives.

Transform the selection

Read the selectedText passed in, change it, and write it back. This covers trimming, case conversion, stripping tracking parameters from a copied link, or reformatting a pasted block. Because the selection arrives up front, these scripts are short — the logic is the transformation, not the plumbing to find the text.

Read and combine fields

Query a few elements off the page, assemble their values into one string, and drop it on the clipboard or into a field. This is the "grab name, title, and company and format them" job, and it pairs naturally with clipboard history for carrying the result to another tab.

Extract and act

Pull a value from the page — an ID, a status, a URL fragment — and use it to build a deep link or trigger the next step. As a step inside a multi-step sequence, an extract-and-act script becomes the bridge between what the page shows and where you go next.

Keeping scripts maintainable

Because a script runs against a live page, it depends on that page’s structure — so the maintenance cost is real. Keep each function small and single-purpose, name it for the task it does, and scope it to the sites it runs on so a selector change on one site cannot break a shortcut you use everywhere.

  • One function, one job — easier to fix when a page changes.
  • Scope each script to its sites so failures stay contained.
  • Prefer stable hooks (labels, roles) over brittle deep selectors.
  • Test on the real page before binding it to a key you rely on.

Frequently asked questions

  • Can I run JavaScript on a keyboard shortcut without building an extension?

    Yes. A dedicated JavaScript runner gives you a built-in editor, so you write and bind a function without packaging or loading an extension. There is no build step and no reload — you save the script and it runs on the next page you open.

  • Does my script have access to the page’s DOM?

    Yes. Your function runs in the page context, so it can read and modify the DOM directly like a userscript. It also receives the current url, title, selectedText, and activeElement up front, so common tasks need no boilerplate to get started.

  • Is running custom JavaScript safe for the host web app?

    It is, because edits go through the browser’s native edit path rather than forcing changes. That keeps the host app’s state and frameworks like React and Vue in sync. You only run code you wrote yourself, scoped to the sites you choose.

  • Does my code or the page data get sent anywhere?

    No. Your JavaScript runs entirely on-device and the page content never touches our servers. Only your account email and plan are stored server-side; on Pro, cloud sync backs up your own functions under your private account so they survive a reinstall.

  • Do I have to code to automate my browser with shortcuts?

    No — JavaScript is optional. Shortcuts, text templates with variables, and recorded click macros need zero code. The JavaScript runner is there for the times a workflow needs real logic, not a requirement for everyday automation.

Everything stays local: your code runs on-device and the page never touches our servers. Write one small script for a task you do daily, and the next time you reach for it, it is a single keystroke.