A Spring MVC interceptor and a servlet filter both let you run code around request processing, but they operate at different layers — one inside the Spring framework, the other at the raw servlet container level.
Key Points: • Interceptors implement HandlerInterceptor and only run for requests handled by DispatcherServlet, so they have access to the handler method and Spring context. • Filters implement the Servlet API's Filter interface and run for every request the container receives, regardless of which framework handles it. • Interceptors are ideal for framework-aware concerns like logging around controller invocation, authentication tied to handler metadata, or modifying the ModelAndView. • Filters are better for cross-cutting, framework-agnostic concerns like compression, character encoding, or CORS that should apply uniformly. • Filters run earlier in the request lifecycle than interceptors, since they wrap the entire servlet dispatch, not just the Spring MVC portion.
Example: A team might use a filter to enforce a consistent UTF-8 character encoding across the whole app, while using an interceptor to log the specific controller method and execution time for every Spring-handled request.
Interview Tip: A concise interview answer is:
"An interceptor is Spring-specific and runs around the handler method inside DispatcherServlet's dispatch, giving it access to the handler and model. A filter is part of the Servlet API, runs for every request before it even reaches DispatcherServlet, and is better suited to generic, framework-agnostic concerns like compression or encoding."