Certain browser events fire far more often than you want to act on them — typing, scrolling, resizing and mouse movement can trigger many times per second. Running expensive work on every single one janks the interface and wastes resources. Debouncing and throttling are the two classic techniques for handling floods of events gracefully, and developers often confuse which is which.
They solve the same broad problem in two distinct ways.
Debouncing: wait for the pause
Debouncing waits until the events stop before acting. It says, in effect, "do nothing until things have been quiet for a moment, then run once". The ideal example is a search box that queries as you type: you do not want a request on every keystroke, only once the user pauses, so debouncing fires a single action after typing settles.
The key property is that a continuous burst of events results in just one action, at the end of the burst.
Throttling: act at a steady rate
Throttling instead lets the action run at most once per interval, no matter how many events arrive. It says "run at a fixed maximum rate while things are happening". This suits continuous processes like reacting to scrolling, where you want regular updates during the activity, not one at the end, but also not one per pixel.
The distinction is timing: debouncing collapses a burst into one action after it ends; throttling spaces actions out evenly during the burst.
Choosing between them
Ask what you actually want. If you only care about the final state after activity settles — a search query, a resize handler that recomputes layout once — debounce. If you want regular responsiveness during ongoing activity — scroll-driven effects, progress updates — throttle at a sensible rate.
Both are small techniques with a large impact on smoothness and efficiency. Knowing which fits the situation is the whole skill.