Weave Code
Laravel Easy Hashids Laravel Package
swiss-devjoy/laravel-easy-hashids
A Laravel package that simplifies Hashids: encode and decode numeric IDs into short, obfuscated strings for URLs and APIs. Includes easy configuration, helpers, and smooth integration with Laravel models and route binding.
Easy HashIds for Laravel Eloquent Models with Livewire Support
Frequently asked questions about Laravel Easy Hashids
- How do I install swiss-devjoy/laravel-easy-hashids in a Laravel app?
- Install it with Composer by running composer require swiss-devjoy/laravel-easy-hashids inside your Laravel project. The package follows the standard Laravel package shape: a service provider, a facade or helper, and a publishable config file holding your salt, minimum length, and alphabet. There is no database migration and no schema change involved, so integration is typically a matter of publishing the config and setting a salt. Expect single-digit engineering hours to wire it up and validate.
- Which PHP and Laravel versions does laravel-easy-hashids support?
- The authoritative answer is the declared constraint block in the package's composer.json, so check that against your target versions before planning the work. This is one of the open questions flagged in the technical evaluation, because the release notes do not clearly document minimum PHP or Laravel bumps across versions. Do not assume compatibility with your current LTS purely from the package description. Verify against your application's Laravel version and the pinned hashids/hashids library constraint it depends on.
- How does laravel-easy-hashids work with route model binding?
- Route model binding is one of the primary integration points the package targets, letting URLs carry short obfuscated strings while your controllers still receive Eloquent models. Keeping encoding at that boundary layer is the correct architecture: hashids belong in routes and API resources, not inside domain models or persistence logic. The failure mode to avoid is sprinkling encode and decode calls across controllers and Blade views, which turns the encoding into an implicit contract baked into every URL you emit.
- Does laravel-easy-hashids work with Livewire components?
- Yes, Livewire support is part of the package's stated scope, which matters because Livewire passes model identifiers through component state and subsequent requests. Having the package handle encode and decode keeps you from hand-rolling hashid logic inside individual components. As with any Livewire model identifier, make sure the decode path still runs through your normal authorization checks before a record is loaded or mutated.
- Is Hashids encryption? Can someone reverse an encoded ID?
- No. Hashids is reversible obfuscation, not encryption: anyone with the salt can decode the ID, and the output is trivially enumerable in volume. Never treat a hashid as an authorization control, and always enforce ownership and permissions server-side on every request. Also keep the salt out of .env.example and public repositories, since a leaked salt means every ID you have emitted is recoverable.
- How do I configure the salt, minimum length, and alphabet in laravel-easy-hashids?
- The package publishes a configuration file where you set the salt, minimum length, and alphabet, which is exactly the set of values that determine the encoded output. Set a distinct salt per environment and treat it as a secret, not as a convenient default you leave in version control. Because these three values define the encoding contract, change them only deliberately and with a migration plan for already-published links.
- What happens to existing URLs if I change the salt or minimum length?
- Any change to the salt, minimum length, or alphabet alters the encoded output, so previously generated URLs break silently at click time rather than throwing an error you would notice. If you must rotate the salt, plan a dual-decode window that accepts both the old and new encoding, and backfill any short codes you have stored. Treat the encoding configuration as a versioned contract and document who owns it.
- Can Hashid collisions happen with laravel-easy-hashids?
- Collision freedom holds for a fixed salt and fixed minimum length, but it is not an absolute guarantee once configuration changes, and very short minimum lengths raise collision risk at scale. The safe practice is to keep the minimum length comfortably generous and pin the config so it cannot drift between environments. Test decoding round-trips at realistic volume rather than assuming the default length is sufficient for your dataset.
- Should I use Hashids or switch to UUIDs and ULIDs for public IDs?
- Hashids is a presentation-layer workaround for exposing sequential auto-increment keys, not a true opaque identifier, so it is a bridge rather than a destination if your roadmap includes UUIDs or ULIDs. The package is easy to adopt and comparatively expensive to un-adopt once short codes are baked into public URLs, analytics, and third-party integrations. Size the investment accordingly and be explicit that this dependency solves a modelling problem only temporarily.
- What changed between v1.0.0 and v1.2.0 of laravel-easy-hashids, and is it safe to upgrade?
- The v1.2.0 release notes are a bare changelog link comparing v1.0.0 to v1.2.0, with no description of what changed across those two minor versions. For a package whose entire value proposition is stability of previously emitted strings, reading that diff is mandatory pre-adoption work: confirm whether the default salt, minimum length, alphabet, config keys, or underlying hashids constraint changed. Then add a test asserting that encoded output is byte-identical to v1.0.0 for the same input and configuration before you upgrade in production.
Weaver
How can I help you explore Laravel packages today?