Protected vs. #[Locked] Public Properties: Which Keeps Internal State Safe in Livewire?

Answer

Both protected/private properties and #[Locked] public properties keep internal state from being sent to the browser, so they offer the same level of exposure safety.

Likely explanation

Livewire strips any property that is not public from the initial HTML payload and from hydration. Adding the #[Locked] attribute to a public property tells Livewire to keep the property in the server‑side session but still exclude it from the payload. Consequently, neither approach allows the frontend to read or write the value via wire:model or action calls.

Confirmed facts (based on Livewire behavior)

• Protected or private properties are never serialized; they cannot be bound with wire:model nor invoked as client‑side actions.
• A #[Locked] public property is also omitted from the payload, but its value is stored in the session between requests and is available on the next hydration cycle.
• Mutating a #[Locked] property during a request updates that server‑side value; the updated value will be used in the following request’s mount or any method that runs before rendering.

Steps to verify for your component

1. Add a protected property, e.g. protected $counter = 0;, and a #[Locked] public $internal = 0;.
2. Render both in the Blade view (they will appear empty).
3. Try to bind them with wire:model – the binder will ignore them, confirming they are not hydratable.
4. From a public action increment $internal, submit a form that triggers another request, and log $internal in the second request – you will see the retained value, proving persistence.
5. Repeat the same test with the protected property; after the second request its value will be reset to the default, showing no persistence.

Missing diagnostic detail

Do you need the internal counter to survive across requests? If yes, use #[Locked]; if the counter only needs to live for the current request, a protected property is sufficient and avoids the extra session storage.