Validate on blur by default, and reserve keystroke-level validation for the narrow cases where live guidance genuinely helps the user get it right. Blur, the moment a field loses focus, is the sweet spot because it gives feedback the instant the user has finished a field, before they have moved on and forgotten it, without interrupting them while they are still typing. Keystroke validation has its place but it is the exception, and submit-only validation is almost always the wrong call because it hoards every problem until the end and dumps them on the user at once. The timing should follow how much real-time help the field actually needs, not a blanket policy.
The reasoning is that validation feedback is only useful when it arrives at a moment the user can act on it without feeling scolded. On blur, the user has signaled they are done with the field, so telling them the email is malformed is helpful and welcome, a quick correction before they lose context. Mid-keystroke, the same message is premature: flagging an email as invalid while someone is three characters into typing it is nagging them about an error they were already on their way to fixing. Submit-only sits at the other extreme, letting the user fill the whole form blind and then confronting them with a list of failures, which forces them to scroll back, re-find each field, and reconstruct what went wrong. Blur is the default because it respects both the user’s flow and their need to know.
The exception that earns keystroke validation is the field where seeing progress in real time is the entire point. A password field with composition rules is the clearest case: showing which requirements are met as the user types turns a guessing game into a guided one, so each character of feedback is help, not interruption. The same logic applies to a username availability check or a character counter on a length-limited message, where the live number is the feature. In those cases the user wants the running commentary because it directly informs what they type next, which is exactly the condition that flips keystroke validation from nagging to genuinely useful.
What sits outside this is that going live should be a deliberate decision tied to a field that benefits, not a default applied everywhere because instant feedback sounds responsive. Validating every field on every keystroke produces the worst experience of all: a form that flashes red errors at users who have not finished typing anything, training them to ignore the warnings entirely. And blur itself has an edge case, since a user who tabs through a field they meant to skip can get a false error, so pair blur validation with the courtesy of not re-flagging a field the user is actively returning to fix.
So set blur as your standard validation trigger and let every field inherit it, then go field by field and ask which ones offer guidance the user needs while typing. Switch those, and only those, to live validation, keeping password rules, availability checks, and counters in that small set. Never default to submit-only, because hiding problems until the end is the pattern users hate most. When you do flag something on blur, keep the message specific and corrective rather than a bare “invalid,” so the feedback the timing delivers is worth the interruption. Default to blur, go live only where it truly guides, and your form will correct people at the moment they can actually use the help.