Product Decisions This Supports
- Feature enablement: Ships opaque, short, reversible public identifiers — share links, referral/invite codes, order and ticket references, deep links in emails and notifications — without changing the database schema or migrating primary keys. The PM-relevant value is "make the product link-safe this sprint," not novel capability.
- Roadmap alignment: Fits an initiative to stop leaking sequential IDs in customer-facing URLs (enumeration, competitive-intel scraping of
/orders/1042). It is a tactical privacy/UX fix, not a platform migration; sequence it alongside, not instead of, any UUID/ULID strategy for new tables.
- Build vs buy: The honest comparison is "integrate a tiny MIT wrapper" vs "two days of engineering to replicate encode/decode + Laravel provider + config + multi-connection support." At 28 stars, archived, and last released 2023-03-05, the true decision is adopt-with-ownership (vendor or fork) rather than buy — we are acquiring ~200 lines of glue, not a vendor relationship.
- Use cases worth scoping: shortened customer-facing IDs; per-tenant salt/alphabet via multiple connections (multi-brand or white-label scenarios); reversible references in exports and webhooks where downstream systems must map back to internal PKs.
- Explicit non-goals: Hashids is obfuscation, not authorization. It must not be pitched as an access-control mechanism — anyone with the salt and a decoder can reverse it, and the salt ships in config. It also does not help if the product needs to sort, filter, or join on the public identifier in SQL, since the column holds the integer.
- Success signals to instrument: reduction in "guessable link" security findings, link shareability/CTR on newly opaque URLs, and support tickets about broken old links after any salt or minimum-length change (there should be zero — salt rotation is a one-way door that invalidates every previously issued ID).
When to Consider This Package
Adopt when:
- The application is on a Laravel version this package supports (effectively Laravel 9–10, PHP 8.1–8.2) and the need is genuinely short, reversible, human-friendly IDs.
- You want the Laravel ergonomics — auto-discovered service provider, facade, publishable config for salt/min-length/alphabet, model and route helpers — rather than writing that glue yourself.
- You need independent ID namespaces (multiple connections), e.g. different salts per tenant or per ID type.
- The team is willing to vendor or fork it into our own namespace and accept ownership, because the upstream is archived. That is the only responsible adoption posture here.
Do not adopt (or adopt only with a fork) when:
- You are starting a greenfield schema or planning a Laravel 11/12 upgrade — there is no forward path from an archived repo, and you will be the one patching it.
- Non-enumerability is a hard security requirement. If disclosure of the salt would be material, use UUIDv7/ULID or a keyed HMAC scheme instead; Hashids is reversible by design.
- Public IDs must be stable across years and across salt rotation, or must be queryable in SQL, or must encode composite/non-integer keys.
- A half-day of due diligence (license, config handling, version floor, CI matrix) cannot be funded — in which case do not ship it.
Look elsewhere for: Sqids (the community successor to Hashids, actively maintained), vinkla/hashids for a more established wrapper, or Laravel's native UUID/ULID support when the identifier is chosen at write time rather than derived at read time.
How to Pitch It (Stakeholders)
For executives (one paragraph): We can remove sequential database IDs from customer-facing URLs — links, orders, invites — in about one to two days of work, using a small MIT-licensed Laravel wrapper. The cost is trivial and the UX/privacy upside is real. The caveat is material and should be stated plainly: the upstream project is archived with a single small maintainer footprint, so we should treat this as code we are adopting and owning (vendored or forked internally), not a dependency we can lean on. No budget ask beyond engineering days; the risk is maintenance, not money or licence. Recommendation: proceed behind a thin internal adapter, with the fork contingency pre-approved.
For engineering leads (the pitch that matters): The package is a thin integration layer over Hashids — its actual value is Laravel service-provider registration, facade bindings, publishable salt/length/alphabet config, model/route helpers, and multi-connection support. That is a few hundred lines we could own outright. Because the repo is archived and last released March 2023, the plan is: (1) half-day spike to confirm the config surface, PHP/Laravel constraints, and exit cost; (2) wrap all calls behind an application-level IdCodec interface so the package is an implementation detail; (3) vendor or fork into our org with the MIT notice preserved; (4) treat the salt as immutable in production — rotating it silently breaks every previously issued link, which is the one operational failure mode that will actually page someone. Do not add it to the critical path of any authorization decision.
The three questions I want answered before sign-off: What breaks if we abandon this in twelve months (exit cost)? Who owns the fork? And has anyone confirmed the config-driven salt cannot end up committed to the repo or echoed in a stack trace? Everything else is a version bump.