original : This sentence is dying, and every time you read it you kill it a little more.
 open 1  : This sgntence is d+ingd !nd every time you re&p it P~u kiKl it a little more}
 open 3  : This sgfxFn0e is d+ingd 3D6 every tibe you re&" it P~u kiKl it a 1ittl> m1re}
 open 6  : TIbm sgf}Fn0e ts d+iqgd yD6 ev*ry tibe you re&" )t Pnu kiKB )t aC1it"l> m1^e}
 open 9  : T/Sm sgf}Fk0- ts d|iqgd HD6 e@*rV tiFe you re&" )t Pnu kiKB )tpaC1it"lYMm1^>}
 open 12 : h/Sm hgf}Nk0-'ts?K|iqgd HD6 e@`~V}t&Fe y%u re&" )2 Pnu kiKB )6UaC1it1lYMm1]b!

That is one sentence in a text file, opened a few times. Nothing edited it between reads. Each open is the only thing that touched it, and each one corrupted it a little more, on disk, permanently, before it showed me anything. The first line is gone now. What is above is all that is left of it, and there is no way back to it.

The tool is called decayfmt. You encode an image or a text file into it, and after that, every time you open it, it permanently corrupts a little before showing you anything. The corruption happens at open time and is written to disk before the file is displayed, not when you close it and not later in the background. If the program is killed right after that write, the damage is already on disk and stays there. There is no recovery from the file alone. The only copy is the one you keep degrading by looking at it.

How quickly it degrades is set by a number in the filename. Images are named like photo.idcy3 and text like note.tdcy7, and the trailing number is the instability, higher meaning more corruption per open. That number is read from the filename and nowhere else, so renaming a file changes how hard the next open hits it. I kept it in the name rather than buried in the header mostly because it is hard to forget it is there.

The corruption is a per-byte chance derived from that number. The probability that any given byte is replaced on a single open is 1 - exp(-x / 10), so an instability of 1 corrupts around a tenth of the eligible bytes each time and 10 corrupts around two thirds, which is to say it is nearly gone after one look. The choice of which bytes, and what to replace them with, comes from the operating system’s cryptographic random generator and is never seeded. That is the one place I was careful. A seeded generator would make the sequence reproducible, and a reproducible corruption sequence is a recoverable one, which would undo the entire point.

There is one behaviour that looks like a bug and is not. If the file is read-only, decayfmt refuses to open it and returns an error instead of showing you anything. The reasoning is that the format’s single rule is that opening costs a corruption, and a file that cannot be written to cannot be corrupted, so opening it would be a free read. Rather than allow that, it fails closed. A locked decayfmt file is not protected, it is just stuck.

The sentence at the top stays readable as it rots because the bytes it swaps in are restricted to printable characters, so text degrades into something half-remembered instead of binary garbage. Images have nothing keeping them legible. Below is one image encoded four times at four different instability values and opened in step, so the same frame decays at four rates at once. The alpha channel is left alone on purpose, so the damage shows up as colour noise rather than holes punched through the picture.

I thought a file you could use up would be funny, so I built one. It works exactly as badly as intended, and I would not keep anything you care about in it. Seems analog.