CONCEPT Cited by 1 source

Double-click-selectable identifier¶

A double-click-selectable identifier is an API identifier whose character set is narrow enough that browsers and terminal emulators treat the whole string as a single word when the user double-clicks it — making the ID one click to select and copy, rather than requiring drag-select across multiple tokens.

Why it's a thing¶

Most developer interactions with API identifiers happen outside the browser: in curl commands, Slack messages, bug reports, documentation, log files, support tickets, pull-request descriptions. In all of these, the developer needs to copy the ID from one place and paste it into another many times per day. The ergonomics of that copy operation — specifically, whether "double-click, Cmd+C" works or whether the user must "drag-select across 5 tokens, Cmd+C" — is a measurable friction point in the developer inner loop.

From PlanetScale's 2022-03-29 post (Source: sources/2026-04-21-planetscale-why-we-chose-nanoids-for-planetscales-api):

They take up a lot of space in a URL: api.planetscale.com/v1/deploy-requests/7cb776c5-8c12-4b1a-84aa-9941b815d873.

Try double clicking on that ID to select and copy it. You can't. The browser interprets it as 5 different words.

It may seem minor, but to build a product that developers love to use, we need to care about details like these.

What breaks word-selection¶

Browsers and terminals use a loose "word-boundary" rule during double-click selection. The hyphen-minus character - is the classic offender — browsers (at least Chrome and Safari) treat - as a word separator by default, so 7cb776c5-8c12-4b1a-84aa-9941b815d873 tokenises as 5 words.

Other boundary-inducing characters: /, :, ., =, ?, &, #, _ (sometimes — varies by browser and by setting), ( / ), whitespace.

Safe characters for single-word-selection: a-z, A-Z, 0-9. Limited to alphanumeric, any ID is reliably one word across all common browsers and terminals.

Identifier formats scored on this axis¶

Format	Example	Double-click-selectable?
UUIDv4 (hyphenated)	`7cb776c5-8c12-4b1a-84aa-9941b815d873`	❌ 5 words
UUIDv4 (hex-only)	`7cb776c58c124b1a84aa9941b815d873`	✅ 1 word
ULID	`01HQF2QXSW5EFKRC2YYCEXZK0N`	✅ 1 word (Crockford base32, uppercase)
NanoID default (see concepts/nanoid-identifier)	`V1StGXR8_Z5jdHi6B-myT`	❌ 2+ words (underscore + hyphen)
NanoID (PlanetScale, base-36)	`izkpm55j334u`	✅ 1 word
Snowflake ID	`7167350074945572864`	✅ 1 word (numeric)
Stripe ID	`cus_abc123def456`	❌ 2 words (underscore)

Note that NanoID's default alphabet includes _ and - — making the default format double-click-hostile. PlanetScale works around this by using a narrower alphabet (0-9a-z only, no symbols). Stripe's prefix-underscore format (cus_...) deliberately splits the ID into a type prefix + value — trading double-click-selectability for type safety.

When the axis matters¶

Public APIs with developer consumers — developers copy-paste identifiers dozens of times per day; friction compounds.
Documentation that quotes real IDs — a tutorial that says "use this ID: ..." is easier to follow if the reader can double-click.
Support conversations — support engineers copy customer-provided IDs into internal tools; hyphenated UUIDs mean every paste carries leading/trailing fragments.
CLI tools — shell word-selection (in tmux, iTerm, gnome-terminal) uses similar rules. foo-bar selects as two words; foobar selects as one.

When it doesn't matter: - Internal / machine-to-machine APIs — no human ever copies the ID. - IDs never exposed in URLs — if the ID only appears in POST bodies, the UX axis vanishes. - Formatted UIs — if the ID always appears with a "copy to clipboard" button, no one double-clicks.

Trade-offs¶

Choosing for double-click-selectability narrows the character set, which narrows the entropy per character:

64-character URL-safe alphabet (NanoID default): 6 bits/char.
36-character base-36 alphabet (PlanetScale): ~5.17 bits/char.
32-character Crockford base32 (ULID): 5 bits/char.
16-character hex: 4 bits/char.

To hit the same collision-resistance budget with a narrower alphabet, the ID must be longer — PlanetScale's 12-char × 36-alphabet gives ~62 bits; the same 62 bits with a hex alphabet requires ~16 characters. Shorter IDs require a wider alphabet and thus more alphabet symbols — eventually including word-breaking characters.

The design axis trades entropy density against word-boundary friendliness. Pick a point on the curve that satisfies both collision-resistance for your table size and the UX properties you care about.

Caveats¶

Not a standardised property — browsers, OSes, and terminal emulators have subtly different word-boundary rules. Chrome on macOS vs Firefox on Linux vs gnome-terminal vs tmux all differ. "Double-click-selectable" is a rule-of-thumb, not a formal guarantee.
User settings can change behaviour — some browsers let users configure word-break characters. IDE settings override terminal settings. Corporate machines sometimes override defaults.
Trades against entropy density — narrower alphabets need longer strings for equal collision resistance.
Underscores are ambiguous — some browsers/terminals treat _ as a word character (joining); others treat it as a separator. Stripe's cus_abc123 is 1 word in some contexts, 2 in others. Don't rely on _.
Doesn't transfer to URLs with paths — even if the ID itself is 1 word, api.planetscale.com/v1/deploy-requests/izkpm55j334u as a whole is still ~5+ words because the slashes/dots are separators. Double-click-selectability optimises the ID in isolation, not the URL in full.
Security-by-obscurity is not the goal — narrow alphabets are for UX, not for making IDs harder to guess. An attacker looking up random IDs doesn't care about word boundaries.
Not all API consumers are developers — machine-to-machine API consumers don't care about this; internal admin tools don't care; only the human-developer inner loop benefits. Worth the character-set tradeoff only when humans are in the loop.

Seen in¶

sources/2026-04-21-planetscale-why-we-chose-nanoids-for-planetscales-api — Mike Coutermarsh (PlanetScale, 2022-03-29) explicitly frames double-click-selectability as one of four selection criteria for PlanetScale's API identifier format, alongside shorter-than-UUID, low collision probability, and cross-language generation. "Try double clicking on that ID to select and copy it. You can't. The browser interprets it as 5 different words." The axis drives the choice of a 36-character base-36 NanoID alphabet (no hyphens, no underscores) over the default 64-char URL-safe alphabet. Canonical first wiki disclosure of the axis as a formal design constraint on API identifier format distinct from collision-resistance, opacity, and sortability.