# Add app shortcuts

> A step-by-step guide to adding shortcuts entries to your PWA manifest, so an installed app's icon offers quick-action jumps straight to key screens.

import CompatTable from '@components/CompatTable.astro';

**In one line:** the manifest `shortcuts` member lets a PWA's icon present a context menu
(for example via right-clicking or long-pressing it) with quick-action entries, so
choosing one navigates the user directly to a specific in-scope URL.

## 1. Declare shortcuts in the manifest

Per the W3C spec, each entry in the `shortcuts` array requires a `name` and a `url`;
`short_name`, `description`, and `icons` are optional:

```json
{
  "shortcuts": [
    {
      "name": "New Invoice",
      "short_name": "New",
      "description": "Create a new invoice",
      "url": "/app/invoice/new",
      "icons": [
        { "src": "/icons/shortcut-new.png", "sizes": "96x96", "type": "image/png" }
      ]
    },
    {
      "name": "Dashboard",
      "url": "/app/dashboard"
    }
  ]
}
```

## 2. Keep every shortcut url in scope

The W3C spec requires every shortcut's `url` to be within the manifest's `scope`; a
`url` outside `scope` is not honored. Within that constraint, MDN describes shortcuts as
direct navigation to a frequently used feature or page — the spec does not also require
that destination to be reachable from the app's regular in-app navigation, so a
shortcut-only entry point is fine as long as it stays in scope.

## Browser & ecosystem support

<CompatTable feature="manifest-shortcuts" />

Per Can I Use, global browser-usage support for the `shortcuts` manifest member is about
80% (79.97% full support plus 0.05% partial), so treat the OS shortcuts menu as a
convenience layer on top of your normal navigation, not the only path to a feature.

## Detecting support and falling back

Per the W3C spec, the user agent or operating system decides how shortcuts are presented
and how many shortcuts are shown to a user — there is no JavaScript API that reports
whether the current browser or OS will expose an OS-level shortcuts menu at all. What a
page can check is its own manifest object, guarding against a missing or malformed
`shortcuts` array before deciding what to show:

```js
function hasDeclaredShortcuts(manifest) {
  if (!('shortcuts' in manifest) || !Array.isArray(manifest.shortcuts) || manifest.shortcuts.length === 0) {
    // No shortcuts declared in the manifest — nothing for an OS menu to expose.
    return false;
  }
  return true;
}
```

That only confirms what your own manifest declares, not whether the visitor's browser and
OS will actually surface it — so the real fallback is unconditional: always render an
always-visible in-app quick-actions menu as a companion entry point, regardless of
`hasDeclaredShortcuts()`'s result, so every visitor has equivalent access whether or not
their browser and OS also expose an OS-level menu.

## Practical checklist

- [ ] Every shortcut `url` is within the manifest `scope` — an out-of-scope url is not
      honored, per the W3C spec.
- [ ] `name` is required on every entry; keep it short enough to display without
      truncation on the narrowest supported platform.
- [ ] Order shortcuts by importance — per the W3C spec, how many are shown and whether
      the list is truncated is left to the user agent and operating system.
- [ ] Always render an in-app quick-actions equivalent — per the W3C spec, presentation of
      the OS shortcuts menu is left entirely to the user agent and operating system.
- [ ] Do not assume every visitor gets the OS shortcuts menu — Can I Use reports about
      80% global browser-usage support for the feature.

## Where to go next

- [Manifest shortcuts reference](/reference/manifest/shortcuts/) — full shortcut object
  syntax and per-platform display limits.
- [manifest: shortcuts support](/compatibility/manifest-shortcuts/) — per-browser
  compatibility data for this manifest member.