Produce an output file without replacing the original
With an installed tidy executable available in your terminal, start by recording its version:
tidy -version
tidy -utf8 -indent -o notice.cleaned.html -f notice.tidy.txt notice.html
notice.html remains the input. The -o option directs the rewritten document to notice.cleaned.html; -f writes diagnostics to notice.tidy.txt. These are the output controls documented in Tidy's command-line guide. Avoid -m for the first pass because it modifies the input in place.
If the command is not recognized, resolve which Tidy executable is installed before trying more options. A web page with a “tidy” button may use a different version or configuration from your local command.
Use a small defect to understand the proposed repair
Save this original fictional notice as the input:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Equipment collection</title>
</head>
<body>
<h2>Collect your equipment</h3>
<p>Bring your booking reference.</p>
</body>
</html>
The closing </h3> disagrees with the opening <h2>. After running Tidy, inspect that heading in the cleaned file and read the associated diagnostic. The intended content remains “Collect your equipment,” and the repaired heading should use a matching end tag. Treat the precise warning wording and rewritten whitespace as version-dependent; they are not evidence that your production notice has been checked.
Next compare the entire files, including the head. A tool may add or normalize markup beyond the line you intended to repair. If a generator meta tag or other unwanted addition appears, consult the installed version's options rather than deleting unexplained output repeatedly.
Interpret the exit status before automating the command
Tidy documents status 0 for a clean result, 1 for warnings, and 2 for errors. In PowerShell, read the status immediately after running the executable:
tidy -utf8 -indent -o notice.cleaned.html -f notice.tidy.txt notice.html
$tidyExit = $LASTEXITCODE
Get-Content -LiteralPath notice.tidy.txt
Write-Output "Tidy exit status: $tidyExit"
A status of 1 needs a warning review, even if the output file exists. Decide whether your build should reject warnings or retain them for review. Do not silently convert every nonzero status to success, and do not assume every nonzero status means that the executable failed to launch.
An error result also needs the diagnostic text. If Tidy cannot determine the intended markup, repair the source yourself and rerun it; forcing output does not supply the missing author intent.
Make repeated runs reproducible
Once the changes are understood, keep the relevant settings in a configuration file:
indent: auto
indent-spaces: 2
wrap: 100
char-encoding: utf8
Save it as tidy.conf, then use:
tidy -config tidy.conf -o notice.cleaned.html -f notice.tidy.txt notice.html
Check option support with tidy -help-config and the versioned configuration reference. Keep the version and configuration with the review record so another maintainer can explain a changed diff.
Review the reader's page before adopting the output
Open the original and cleaned copies through the same local server. Compare the heading order, intentional spacing, links, and any form or script that the notice contains. Tidy diagnoses and repairs markup; it does not know whether a booking URL points to the correct event or a notice states the right collection date.
If the source contains server-side templates, check the generated HTML separately before applying a repair tool to the template itself. For indentation without a repair pass, HTML formatting covers the narrower task. Adopt the cleaned file only after the diff and the displayed notice both preserve the intended message.