Render vs Redirect
Fast recall
Quick revision
Core answer
render builds a response in the current request, using a template or supplied body; it does not run another controller action or change the browser URL. redirect_to returns a 3xx response with a Location header, telling the client to make a new request, so the URL and request state change. Render is typical for showing validation errors; redirect is typical after a successful write. Neither call automatically stops the Ruby method.Whether you know render composes the current response (one request) and redirect starts a new one (two requests), and the POST/redirect/GET rule.
rendering after a create (refresh resubmits the form), or redirecting to re-render a form with validation errors (you lose the @post and the errors).
render composes the current response (one request); redirect_to starts a new request (two). After create/update/destroy, redirect (POST/redirect/GET); render to show a form with errors.
Interview-ready guide
Interview answer
render and redirect_to choose different HTTP flows. Rendering creates the response body during the current controller request. Redirecting sends a response that instructs the client to visit another URL in a separate request.
For example, when @article.save fails validation, render :new, status: :unprocessable_entity shows the form again with the same in-memory Article and its errors. Rails uses the new template but does not call the new action, and the browser remains on the submitted URL.
After a successful create, redirect_to @article, status: :see_other gives the browser the article URL. The follow-up GET loads the saved resource cleanly and refreshing that page does not repeat the original POST. Flash values can cross that redirect; ordinary instance variables cannot because the next request gets a new controller instance.
Neither render nor redirect automatically returns from the Ruby method. If code later attempts another response, Rails raises a double-render error, so an early branch may need return or a mutually exclusive control structure.
The decision is therefore based on request lifecycle: render when the current request already has the state needed for its response, redirect when the client should begin a new request at a canonical URL.
Render vs Redirect
Direct Answer
render builds a response in the current request, using a template or supplied body; it does not run another controller action or change the browser URL. redirect_to returns a 3xx response with a Location header, telling the client to make a new request, so the URL and request state change. Render is typical for showing validation errors; redirect is typical after a successful write. Neither call automatically stops the Ruby method.
Deep Dive & Architecture
A rendered response contains its final status, headers, and body immediately. Template selection is only one way to form that body; a controller can also render JSON, plain text, or no body. Selecting another action's template changes presentation, not which action's setup code has run.
A redirect response normally contains a 3xx status and Location. The current server-side work ends with that response, then the browser or API client decides whether to follow it. The follow-up request passes through routing, authentication, controller construction, and data loading again.
This explains state behaviour. Validation errors live on the unsaved model object and remain available to a rendered form in the same request. They disappear across a redirect unless deliberately stored, while a flash message is designed to survive into the next request.
The post-redirect-get pattern makes successful form submissions easier to refresh and bookmark. For invalid input, redirecting usually loses the rejected values and errors, so rendering with an appropriate non-success status is the clearer contract.
Code Example
def create
@article = Article.new(article_params)
if @article.save
redirect_to @article, status: :see_other
else
render :new, status: :unprocessable_entity
end
end
def leave_early
redirect_to root_path
return # later response code must not run
end
Common Mistakes & Pitfalls
rendering after a create (refresh resubmits the form), or redirecting to re-render a form with validation errors (you lose the @post and the errors).
Check your understanding
Answer these without looking back at the article.
- Does `render :show` execute the `show` action?
- Why is render usually better than redirect after validation failure?
- Why can code after `redirect_to` cause a double-render error?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.