Laravel Hashids

Laravel Hashids wires the framework-agnostic hashids/hashids library into Laravel’s conventions: a service provider registers connection-based HashidsManager/HashidsFactory instances from config, and a Hashids facade gives you Hashids::encode()/Hashids::decode() calls (or constructor-injected access to the manager) anywhere in the app. It’s built on Graham Campbell’s graham-campbell/manager package, the same multi-connection pattern used by several other Laravel bridge packages, so you can configure multiple named Hashids connections (different salts/lengths/alphabets) and switch between them.

The README is upfront that Hashids’ original author has moved on to a successor project called Sqids, and notes Sqids’ API is simple enough not to need a Laravel wrapper at all — but Hashids itself, and this bridge, continue to be maintained for existing projects that already depend on Hashids-format IDs (e.g., for backwards-compatible URLs).

What You Get

• A HashidsServiceProvider that registers config-driven Hashids connections and binds them into Laravel’s container
• HashidsManager/HashidsFactory (built on graham-campbell/manager) for creating and switching between multiple named Hashids connections, each with its own salt/length/alphabet
• A Hashids facade exposing static encode()/decode() calls that proxy to the default (or a named) connection
• Standard Laravel package conventions — auto-discovered service provider and facade alias — so installation is just composer require plus a config file

Common Use Cases

• Obfuscating sequential auto-increment database IDs in public-facing URLs so they aren’t trivially enumerable or predictable
• Generating short, URL-safe, reversible tokens for resources (invoices, orders, referral codes) without persisting a separate lookup table
• Applications needing multiple Hashids “connections” with different salts for different resource types (e.g., separate encodings for users vs. orders)
• Maintaining backwards compatibility for existing Hashids-encoded URLs in Laravel apps that haven’t migrated to a newer ID-obfuscation scheme like Sqids

Under The Hood

Architecture — The package is a thin Laravel-conventions layer (206 lines across src/) over hashids/hashids: HashidsServiceProvider (83 lines) reads the config/hashids.php connections array and registers a singleton HashidsManager, which extends graham-campbell/manager’s generic multi-connection manager pattern (HashidsFactory builds a Hashids instance per named connection config). The Hashids facade resolves the manager from the container and forwards static calls to it, so Hashids::encode() ultimately calls the currently-selected connection’s underlying hashids/hashids instance. Tech Stack — PHP 8.3+, illuminate/contracts/illuminate/support ^13.0 for Laravel integration, graham-campbell/manager ^5.3 for the connection-manager pattern, and hashids/hashids ^5.0 as the actual encoding engine. Dev dependencies include Graham Campbell’s testbench/analyzer tooling, Mockery, and PHPUnit. Code Quality — 6 test files cover the service provider, manager, and facade wiring; the codebase is small and stable, with low recent commit activity reflecting a feature-complete bridge rather than one under active expansion — consistent with the README’s note that the ecosystem is shifting toward the successor Sqids project. API Design — The facade-based API (Hashids::encode(4815162342), Hashids::decode('1LLb3b4ck')) matches idiomatic Laravel package conventions exactly, and dependency-injecting HashidsManager directly is equally supported for consumers who avoid facades — both paths require essentially zero boilerplate beyond publishing the config file.