webpatser/laravel-uuid for Laravel 13 UUID Generation

What webpatser/laravel-uuid Adds to Laravel

webpatser/laravel-uuid is a Laravel package for generating and validating UUIDs according to RFC 4122. The package description limits its built-in UUID versions to versions 1, 3, 4, and 5. That makes it relevant to Laravel developers who need opaque identifiers, UUID primary keys, or form validation involving UUID values.

The repository presents two distinct uses. One is direct identifier generation through Laravel's `Str` facade. The other is automatic UUID generation for Eloquent models through the `HasUuids` trait. The README also refers to validation rules, but it does not include the rule class, method name, or a complete validation example. Its validation documentation is therefore not available in the repository excerpt.

This is a focused package rather than a general Laravel utility. The listed topics, `laravel-uuid` and `laravel-validation`, match its two principal responsibilities: UUID generation and UUID acceptance in application input. The repository contains `src/` and `tests/`, but the README does not describe the internal namespace layout beyond `Webpatser\LaravelUuid\HasUuids`.

The package is not archived, and its last push was on 2026-07-02. That date shows recent repository activity, although the only listed release is version 1.3 from 2014-09-29. A recent commit and an old tagged release describe different things: the former concerns repository changes, while the latter is the available release history shown in the project record.

UUID Generation Through Str and HasUuids

The documented direct API uses `Illuminate\Support\Str`. The README supplies two generation calls. `Str::fastUuid()` returns a generated UUID, while `Str::fastOrderedUuid()` returns a UUID intended for database optimization. The README labels the latter “Database-optimized,” but does not explain its ordering properties or database-specific implementation. For a schema that depends on index locality, that omission deserves attention before selecting it.

Eloquent integration is enabled by applying `HasUuids` to a model. Based on the README example, the trait supplies automatic UUID generation for that model's UUID key. The excerpt does not state when the value is assigned, whether existing identifiers are replaced, how non-UUID keys behave, or how collision handling works. Those lifecycle details must be checked in the external API documentation or source before applying the trait to an established model.

The repository description also mentions RFC 4122 versions 1, 3, 4, and 5. The quick-start example, however, exposes only the two Laravel `Str` methods and the model trait. It does not show package-specific calls for selecting versions 1, 3, or 5. It would therefore be incorrect to assume that the same syntax can select every supported version.

The generation examples call Laravel's facade, which makes the package fit into framework code without defining a separate service interface in the excerpt. The source repository is the authoritative place to determine whether the trait delegates to `Str`, whether validation is registered through a service provider, and how the package behaves under custom Eloquent key configurations.

Installing webpatser/laravel-uuid on Laravel 13

The README requires PHP 8.5 or later and Laravel 13.x. Install the package with Composer from the project directory:

composer require webpatser/laravel-uuid

After Composer completes, the documented first direct use is available through Laravel's `Str` facade:

use Illuminate\Support\Str;

$uuid = Str::fastUuid();
$ordered = Str::fastOrderedUuid();

The first call represents ordinary UUID generation. The second requests the package's database-oriented variant. The README does not publish example output, so the expected result is a UUID value rather than a specific string that readers should compare against.

For an Eloquent model, import the trait and add it to the model class. The README example omits the namespace declaration for `Model`, so this excerpt is illustrative rather than a complete drop-in class:

use Webpatser\LaravelUuid\HasUuids;

class User extends Model
{
    use HasUuids;
}

With `HasUuids` present, the README states that UUID generation is automatic. It does not document migrations, primary-key casting, fillable fields, custom key names, or behavior when a model is created without an explicit identifier. A first real use should therefore begin with `Str::fastUuid()` in an existing Laravel 13 application before relying on automatic model keys.

RFC 4122 Coverage and Validation Boundaries

The stated scope is RFC 4122, with built-in support for UUID versions 1, 3, 4, and 5. This is a meaningful boundary. The package does not present itself as support for every UUID version, and applications requiring a version outside that set should not treat this repository as a general implementation of every identifier format described by RFC 4122.

Validation is one of the package's advertised capabilities, yet the cleaned README contains no rule declaration or request-validation example. The external documentation at `https://documentation.downsized.nl/laravel-uuid` is identified as the place for the complete examples and API reference. Without that reference in the repository excerpt, the exact validation syntax cannot be reproduced safely.

The supported-version claim also does not explain the inputs needed for version 3 or version 5. Those versions conventionally depend on a namespace and a name, while version 1 depends on time and node-related data, but the project does not document package-specific calls for any of them. Version 4 is represented indirectly by the generic generation examples. Readers who need deterministic version 3 or 5 values must verify the documented API rather than infer its shape from `Str::uuid()`.

This limited public explanation is the main adoption risk. The feature list is clear, but key operational details are delegated to an external documentation site.

Constraints, Maintenance, and License Checks

The clearest technical constraint is platform scope. The README requires PHP 8.5+ and Laravel 13.x. An application on an earlier Laravel or PHP release would not match the documented requirements. The package is therefore better viewed as a version-specific integration than as a portable UUID library for arbitrary PHP applications.

A second constraint concerns Eloquent control. The short trait example says little about preserving identifiers supplied by callers, configuring key types, or integrating with existing records. Models that depend on client-generated keys, binary UUID columns, or custom creation workflows need more detail than the README provides. Automatic generation sounds convenient, but its interaction with application-level assignment rules can affect data integrity if left unexamined.

Maintenance evidence is mixed but interpretable. The repository is not archived, and the last push was on 2026-07-02. The listed release history contains only version 1.3, released on 2014-09-29. No upgrade guide, supported-version policy, migration notes, or compatibility table appears in the README excerpt. Recent repository activity reduces the question of abandonment, but it does not document the upgrade path between Laravel versions.

The README labels the project as using the MIT License. The listed repository entries do not include a `LICENSE` file, however, so the exact license text and whether it covers every distributed component should be checked before redistribution or compliance work. No legal conclusion can be drawn from the badge alone.

webpatser/laravel-uuid Compared with Laravel Str UUIDs

Laravel's `Str` class is already the entry point shown for UUID generation in this package. That creates a real alternative question: does the project add enough value beyond Laravel's own UUID facilities to justify another dependency?

The documented distinction is package-level integration. `webpatser/laravel-uuid` provides the `HasUuids` Eloquent trait and advertises validation support, while the README's direct generation examples still call `Str::fastUuid()` and `Str::fastOrderedUuid()`. An application that only needs one generated UUID may therefore remain within Laravel's framework API. An application wanting UUID model-key behavior or package validation rules has a more specific reason to install it.

This comparison also exposes missing detail. The README calls `fastUuid()` “15% faster than Str::uuid()” but supplies no benchmark method, dataset, PHP version, Laravel version, or result format. That percentage should be treated as a project claim, not an independently established performance result. The package may save integration work, but the repository excerpt does not quantify the maintenance cost of adding it.

Neither approach should be selected from the feature label alone. The first verification point is whether the target Laravel 13 application needs `HasUuids` or validation behavior beyond the `Str` calls it already uses.

Editorial conclusion

Adopt webpatser/laravel-uuid when a PHP 8.5 and Laravel 13 application specifically needs its Eloquent UUID-key trait, database-oriented UUID option, or documented validation support. Do not add it for a single `Str` UUID call unless its extra integration is required. Verify the external documentation for key assignment behavior and validation syntax, confirm compatibility with the installed framework, and inspect the repository's license file before distribution because the README labels it MIT while no `LICENSE` entry is listed.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. webpatser/laravel-uuid on GitHub