A webpage is not always broken because of a large mistake. Small details can produce exactly this problem: debugging: checkbox missing from request. This guide shows you what to look for, a concrete fix, and how to check that it worked.
The Idea in Plain English
Unchecked checkboxes are normally omitted from the submission, not sent as false. Server code needs to account for absence.
You can test this using a small local HTML file. Change one part at a time and check the result in the browser before adding more code.
A Working Example
The first part shows a problem. The second part shows a safer or more accurate version. Compare them before reading the explanation.
<!-- Problem -->
<label><input type="checkbox" name="newsletter"> Subscribe</label>
<!-- Corrected example -->
<label><input type="checkbox" name="newsletter" value="yes"> Subscribe</label>What Each Part Does
- The label tells visitors and assistive tools what a control is for.
- The input creates a field; its type changes the editing controls and the name identifies submitted data.
- type chooses the relevant kind of script, input, media or embedded object.
- name identifies a field in submitted form data or a named metadata entry.
- value specifies a form value or a machine-readable value.
Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
Try It Yourself
Check the request both ways; newsletter=yes exists only when selected.
Common Beginner Mistakes
- Check the underlying cause before changing unrelated tags.
- Changing several parts of the example at once, making it difficult to see which part caused a different result.
- Choosing a tag only because its default appearance looks right, without checking whether it describes the content correctly.
Key Takeaways
- Unchecked checkboxes are normally omitted from the submission, not sent as false. Server code needs to account for absence.
- Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
- Test the markup in a browser, and check accessibility and real-world behavior where relevant.