Creating a Custom Helper Class in Laravel

Not every piece of reusable logic belongs in a model, a controller, or a full service class registered in the container — sometimes a plain PHP class with static (or instance) methods is genuinely the simplest fit, especially for small, stateless utility logic specific to your application.

1. Create the class

// app/Support/TextHelper.php
namespace App\Support;

class TextHelper
{
    public static function excerpt(string $text, int $length = 150): string
    {
        return Str::limit(strip_tags($text), $length);
    }
}

2. Use it via its namespace

use App\Support\TextHelper;

$summary = TextHelper::excerpt($post->body);

3. Optional: a shorter alias

If typing the full namespace repeatedly is annoying, register a class alias in bootstrap/app.php (or the legacy config/app.php aliases array on pre-Laravel-11 projects):

class_alias(\App\Support\TextHelper::class, 'TextHelper');

This lets you call TextHelper::excerpt() anywhere without the use import — convenient, but used sparingly, since aliasing every class you write makes it harder to trace where a class actually comes from.

Class vs. plain function helper — which to use

A static-method class (like this one) groups related utility methods under one namespace and is easy to autoload via Composer's PSR-4 rules automatically. A plain global function (registered via composer.json's autoload.files, covered in our helper functions guide) is simpler for a single one-off function but doesn't group related logic the way a class does. For more than one or two related utilities, a class is usually the more maintainable choice.

When to upgrade to a real service class instead

If the "helper" starts needing constructor dependencies (another service, a config value, a repository), it's outgrown a simple static-method class — that's the point to make it a proper injectable service registered in the container instead, rather than reaching for static properties to hold state that doesn't belong there.