PSR standards in 2026: which PHP-FIG specs your project needs

PSRs are the shared interfaces and conventions published by the PHP Framework Interop Group (PHP-FIG). They are why a logger, cache, HTTP client or clock from one vendor plugs into code written against another. In October 2026 most projects need only a handful: PSR-4 for autoloading, PER Coding Style for formatting, and the interface PSRs (logging, containers, HTTP, cache, events, clock) wherever your code crosses a library boundary.

This guide lists the current status of every PSR as published on php-fig.org, explains which ones to adopt and shows a small project that uses three of them. The example was installed with Composer and run on PHP 8.5.7.

The PSR list and status in October 2026

The PSR index lists numbers 0 to 22. Status matters: deprecated and abandoned PSRs should not be adopted in new code, and drafts can still change.

PSR-4: the one every project uses

PSR-4 maps a namespace prefix to a base directory. The specification requires a top-level vendor namespace, sub-namespaces that match subdirectory names, a file name that matches the class name plus .php, and case-sensitive matching. It also says autoloaders must not throw exceptions or raise errors.

You rarely write the autoloader yourself; Composer generates it from composer.json:

{
    "name": "acme/billing",
    "type": "project",
    "require": {
        "php": ">=8.4",
        "psr/clock": "^1.0",
        "psr/log": "^3.0"
    },
    "autoload": {
        "psr-4": {
            "Acme\\Billing\\": "src/Billing/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Acme\\Billing\\Tests\\": "tests/"
        }
    }
}

Composer's schema documentation requires namespace prefixes to end in \\ (an escaped backslash in JSON) to avoid conflicts between similar prefixes. With the mapping above, Acme\Billing\InvoiceReminder lives in src/Billing/InvoiceReminder.php. In production, run composer dump-autoload -o (or install with --optimize-autoloader) to turn PSR-4 rules into a class map; in our demo it reported Generated optimized autoload files containing 12 classes.

The most common PSR-4 bug is case. A file named invoiceReminder.php works on macOS, whose default file system is case-insensitive, and then fails on a Linux server. The specification requires the case to match exactly.

Coding style: PSR-12 is replaced by PER Coding Style

PSR-12 is still listed as accepted, but PSRs are frozen once accepted, so it cannot describe syntax added after 2019. PHP-FIG now publishes the PHP Evolving Recommendation (PER) Coding Style, currently version 3.1, which states that it "extends, expands and replaces" PSR-12 and requires PSR-1.

The core rules are familiar: four spaces of indentation and no tabs, a soft line limit of 120 characters with no hard limit, and lowercase keywords and types. Newer versions add rules for modern syntax, including:

• Enums: PascalCase case names and no space before the colon in enum Suit: string.
• Property hooks: brace placement for long hooks and single spaces around => for short ones.
• Attributes: each attribute block on its own line above the declaration.
• Short closures: no space after fn, so fn($x) => $x * 2.
• The pipe operator: |> is formatted as a binary operator.
• Compound types: null last in unions, and ?T preferred for a single nullable type.

Do not format by hand. PHP-CS-Fixer ships an @PER-CS rule set that follows the newest PER version it supports, plus pinned sets such as @PER-CS3x0 if you want upgrades to be explicit:

<?php
// .php-cs-fixer.dist.php
$finder = (new PhpCsFixer\Finder())->in([__DIR__ . '/src', __DIR__ . '/tests']);

return (new PhpCsFixer\Config())
    ->setRules(['@PER-CS' => true])
    ->setFinder($finder);

Interface PSRs: depend on contracts, not vendors

The interface PSRs pay off when a class needs a service it should not care about. This class depends on PSR-20 for time and PSR-3 for logging, and on nothing vendor-specific:

<?php

declare(strict_types=1);

namespace Acme\Billing;

use Psr\Clock\ClockInterface;
use Psr\Log\LoggerInterface;

final readonly class InvoiceReminder
{
    public function __construct(
        private ClockInterface $clock,
        private LoggerInterface $logger,
    ) {
    }

    public function isOverdue(\DateTimeImmutable $dueDate): bool
    {
        $overdue = $this->clock->now() > $dueDate;

        if ($overdue) {
            $this->logger->info('Invoice overdue since {due}', [
                'due' => $dueDate->format('Y-m-d'),
            ]);
        }

        return $overdue;
    }
}

In tests, a frozen clock replaces the system clock with a few lines:

<?php

declare(strict_types=1);

namespace Acme\Billing\Tests;

use Psr\Clock\ClockInterface;

final readonly class FrozenClock implements ClockInterface
{
    public function __construct(private \DateTimeImmutable $now)
    {
    }

    public function now(): \DateTimeImmutable
    {
        return $this->now;
    }
}

With the clock frozen at 9 October 2026, our run returned true for an invoice due on 1 October and logged INFO: Invoice overdue since 2026-10-01, and returned false for one due on 31 October. No sleeping, no mocking framework and no global state were needed. The installed packages were psr/clock 1.0.0 and psr/log 3.0.2.

The HTTP family: PSR-7, 15, 17 and 18

These four work together. PSR-7 defines immutable request and response messages, PSR-17 defines factories to create them, PSR-15 defines middleware and request handlers, and PSR-18 defines a client that sends a PSR-7 request and returns a PSR-7 response. A middleware written against them runs in any PSR-15 compatible framework:

<?php

declare(strict_types=1);

namespace Acme\Http;

use Psr\Http\Message\ResponseFactoryInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;

final readonly class MaintenanceMode implements MiddlewareInterface
{
    public function __construct(
        private ResponseFactoryInterface $responses,
        private bool $enabled,
    ) {
    }

    public function process(
        ServerRequestInterface $request,
        RequestHandlerInterface $handler,
    ): ResponseInterface {
        if (!$this->enabled) {
            return $handler->handle($request);
        }

        return $this->responses->createResponse(503)
            ->withHeader('Retry-After', '600');
    }
}

Notice that the middleware asks for a PSR-17 factory instead of creating a response class from a specific library. That single decision keeps it portable.

Containers, events and caches

• PSR-11 standardises reading from a container with get() and has(). Type-hint it in framework glue code, not in domain classes, which should receive their dependencies through constructors.
• PSR-14 lets libraries dispatch events without choosing an event system for you.
• PSR-16 is the simpler cache interface and is enough for most applications; PSR-6 adds cache items and deferred saves for advanced cases.

Gotchas

• Adopting a draft. PSR-5 and PSR-19 (PHPDoc) are still drafts after many years. Static analysers define their own PHPDoc conventions in practice.
• Citing PSR-2. It is deprecated. Linters and job descriptions that still name it should move to PER Coding Style.
• Implementing interfaces you do not need. PSRs are for boundaries between packages. Inside your own application, a concrete class is often clearer.
• Forgetting the provide key. Libraries that implement an interface PSR usually declare it in Composer's provide section (for example psr/log-implementation), which lets you require an implementation without naming a vendor.

What to do next

Check that every class in your project follows your PSR-4 mapping by running composer dump-autoload -o and reading the warnings. Add PHP-CS-Fixer with @PER-CS to CI. Then look for direct dependencies on a specific logger, clock or HTTP client in your domain code and replace them with the matching PSR interface. Those three changes give you most of the value the PSRs offer.