Using Named Routes in Redirects and Forms

In a Laravel application, a form action tells the browser where to send submitted data, and a redirect tells the browser where to go next. A named route gives Laravel a stable label for a route, so your code can ask for the route’s URL without writing its path directly. When you keep that label while changing the path, Laravel updates the generated URL for forms and redirects that use it.

A route name tells Laravel which route to use; the path defines the URL Laravel builds. For example, posts.update can name a route whose path is /posts/{post}. The route definition also specifies which HTTP method it accepts. Laravel looks up the route by name, then uses its path and any supplied parameters to generate a URL.

Name routes where you define them

Attach a name to a Laravel route with name(...). Route names should be unique, and the route definition still controls the path and accepted HTTP method, as the Laravel routing documentation describes.

use App\Http\Controllers\PostController;
use Illuminate\Support\Facades\Route;

Route::get('/posts/{post}', [PostController::class, 'show'])
    ->name('posts.show');

Route::put('/posts/{post}', [PostController::class, 'update'])
    ->name('posts.update');

Here, posts.update identifies the route that accepts PUT requests, while posts.show identifies the route that accepts GET requests. The {post} placeholder marks a value the URL needs, such as a post’s ID. Giving the routes distinct names lets form code and redirect code refer to the intended destination clearly.

Generate a form action from its route name

In a Blade template, call route(...) to generate a URL for a named route, then place that URL in the form’s action attribute. Pass the value for each required path placeholder as a parameter:

 $post->id]) }}">
    @csrf
    @method('PUT')

    <!-- Form fields -->
    <button type="submit">Save</button>

The route() helper generates the URL, and Blade inserts it into the rendered HTML. Laravel’s URL generation documentation describes how named routes and supplied parameters produce URLs; the Blade documentation covers rendering expressions in templates.

The browser submits an HTML form using POST here. @method('PUT') adds a hidden field so Laravel treats the request as a PUT request, matching the route definition. @csrf adds the CSRF token Laravel expects for routes in the web middleware group. The named URL supplies the destination, but it does not change the form’s HTTP method or replace CSRF protection.

Redirect to a named route

After handling a request, return a redirect that sends the browser to the route for the next page. For example, after updating a post, redirect to its show page:

return to_route('posts.show', ['post' => $post->id]);

Laravel also supports redirect()->route(...) for named-route redirects. Both approaches generate the destination URL from the route name and its parameters; to_route() is a helper documented alongside other Laravel helpers.

A form action and a redirect use the generated URL in different ways. The form puts it in the HTML so the browser can submit a request there. A redirect returns a response that tells the browser to navigate to the URL. In either case, make sure the route name exists and that the route accepts the intended request.

Keep route names stable during path changes

Code that uses a route name does not have to repeat the route’s path. Suppose the posts.show route changes from /posts/{post} to /articles/{post}. Code that calls route('posts.show', ...) still generates the path from the updated route definition, as long as the route keeps the same name. Laravel describes this separation in its URL generation documentation.

This works only while the route keeps its name and that name stays unique. Renaming or removing posts.show breaks code that still refers to it, and incorrect or missing route parameters can prevent Laravel from generating the intended URL. When you change a path, keep its route name and pass each required placeholder value in every call.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com