PHP Anonymizer

Forum PHP leaks in layers

PHP gets shared more publicly than most languages, in forums, WordPress support threads, Laracasts discussions, and pasted into chatbots. Each snippet leaks on three layers at once. The identifiers spell out domain and architecture. The strings hold the concrete facts, routes, table names, file paths, customer-facing wording. The comments explain what the other two meant. A useful question needs none of the three, it needs the code's shape and the framework vocabulary, which is precisely the part that is public knowledge anyway.

Two modes and a key

In anonymize mode, your classes become Class1, functions fn2, properties prop3, variables $var4 with the dollar sign intact, constants CONST_5, and namespace chains Pkg1\Pkg2. String literals turn into 'str_1', comments are dropped unless you keep them, and the formatting is preserved character for character. In restore mode the same key turns an edited answer back into your naming, flags placeholders it never issued, and leaves genuinely new names alone.

The key lives in this browser's localStorage and downloads as JSON when a colleague needs to restore on their machine. No part of the process touches a server.

Sigils, superglobals, $this

Renamed PHP has to stay PHP. Variables keep their sigil so $invoice becomes $var3, not a bare token that would not parse. $this, self, parent and the superglobals $_POST, $_SESSION, $_SERVER are language, not information about you, and stay. Magic methods like __construct and __toString stay as well, declaring them is following the language, not naming your domain.

One consequence worth noticing: a snippet full of $var1, $param2 and fn3( still reads fluently as PHP, which is what keeps the answers good.

Laravel, Symfony and the App root

Vocabulary from known vendors survives, Illuminate, Symfony, Doctrine, Carbon, Guzzle, PHPUnit, Livewire, Filament, Spatie packages and many more, recognized on their use lines and as fully qualified names in the code. The standard functions from str_replace to preg_match are always readable. Laravel's default roots App, Database and Tests stay as bare words since every Laravel project shares them, while everything after the backslash is yours and gets placeholders. App\Services\Billing\PayoutService becomes App\Pkg1\Pkg2\Class3.

Facades and Eloquent keep their surface too, so Invoice::where('paid', false)->get() stays diagnosable as an Eloquent query after the model and the column are gone.

Double quotes interpolate

The classic manual-redaction mistake in PHP sits in the string syntax. Single-quoted strings are plain text, but double-quoted strings and heredocs execute the variables inside them, and hand-redaction routinely misses that second category.

$msg = "Reminder sent to {$customer->email} for INV-{$invoice->number}";
$sql = <<<SQL
SELECT company_name FROM acme_customers WHERE churn_risk > 0.8
SQL;

$msg = "str_1 {$var1->prop2} str_2-{$var3->prop4}";
$sql = <<<SQL
str_3
SQL;

The tool lexes strings the way the engine does. Literal pieces are masked, embedded variables and {$expressions} stay code and are renamed consistently with the rest of the file, and a nowdoc (<<<'SQL') is treated as the plain text it is. Strings that act as syntax, format characters, HTTP methods, Laravel validation rules like required or max:255, cast types, guard names, stay readable and are listed as kept.

What a reader still sees

Role guessing is heuristic, so an unusual construct may label a name with the wrong role, which changes nothing about the restore. Numbers stay, long ones are flagged. And structure survives by design, a controller with validation, a query and a redirect is recognizable as exactly that. We share anonymized code with language models ourselves and the price we pay is an occasional answer that misses a detail the names would have carried, a trade we take for anything client-related.

Posting PHP publicly, the careful way