Report a bug
If a generated file will not open, comes out the wrong size, or something on the site behaves oddly, this form builds a report that can be acted on: what went wrong, the steps to reproduce it, what you expected instead, and which page or format was involved.
Your browser details are filled in automatically so you do not have to look them up, and you can edit or clear them before sending. The page transmits nothing by itself — it hands the finished report to your own email client, so you keep a copy of what you sent.
What makes a file-generator bug reproducible is a specific combination, so the form asks for the format, the size, the content option and the condition you chose. Those four decide which code path ran. A report saying a download was broken cannot be investigated; a report saying a 5 KB XLSX with the spreadsheet content option came out unreadable in Excel names one path and is usually fixed the same day.
It also helps to say what rejected the file and how. A parser's own error message — the line it stopped on, the byte offset, the exception class — is far more use than a description of the symptom, because it distinguishes a genuinely malformed file from a reader being stricter than the specification requires. Both are worth knowing about and they have opposite fixes.
Some behavior looks like a bug and is not, and these have all been measured rather than assumed. A file named CON.json saves as _CON.json in Chrome and Untitled.json in Firefox, because CON is a reserved device name on Windows and both browsers rename rather than refuse. A 255-character filename saves nothing at all in Chrome, silently, because the name plus its directory exceeds Windows' 260-character path limit; Firefox truncates it and saves. A leading dot is stripped by both browsers, so the file is not hidden anywhere. Those three are the operating system and the browser behaving correctly, and they are deliberate test cases rather than defects.
Deliberately broken files are also not bugs. Any format can be generated invalid, corrupted or incomplete, and a file produced that way is supposed to fail: the damage is applied to the bytes so that a parser rejects it for the reason you would expect. If you asked for a corrupted PNG and your image library refuses it, that is the feature working. What is worth reporting is the opposite case — a file marked corrupted that a real reader opens happily, which means the damage was not severe enough to matter.