How to Get the Current Absolute URL in Ruby on Rails

By the end of this page, you will understand how Rails represents request URLs, how to get the full current URL in a view or controller, and when to use methods like request.url, request.original_url, request.path, and request.fullpath. You will also see common mistakes and practical examples.

In Rails, the request object gives you information about the current HTTP request. This includes the host, protocol, path, query string, headers, and more.

When people ask for the current absolute URL, they usually mean the full address of the current page, such as:

https://example.com/products?page=2

That full URL contains:

• Protocol: https://
• Host: example.com
• Path: /products
• Query string: ?page=2

A relative URL only includes the path and maybe the query string, for example:

/products?page=2

In Rails, different request methods return different parts of the URL:

• request.url → full absolute URL
• request.original_url → original full URL
• request.path → path only
• request.fullpath → path plus query string

This matters because using the wrong method can lead to bugs. For example:

• generating incorrect redirect targets
• sharing incomplete links
• storing the wrong page location for analytics
• creating broken callback or return URLs

If you need the full current URL in a Rails view, request.url is usually the direct answer.

Think of a URL like a postal address.

• Protocol is the delivery method: http or https
• Host is the city and street: example.com
• Path is the apartment number: /products
• Query string is extra delivery instructions: ?page=2

Rails lets you ask for different parts of that address.

• request.path asks for just the apartment number
• request.fullpath asks for apartment number plus instructions
• request.url asks for the complete mailing address

So if you want the whole address, ask Rails for the whole address, not just one part of it.

The most common way to get the current absolute URL in Rails is:

request.url

In a view:

<p>Current URL: <%= request.url %></p>

Example output:

Current URL: https://example.com/products?page=2

You can also use:

request.original_url

Example:

<p>Original URL: <%= request.original_url %></p>

Common request URL methods

request.url
request.original_url
request.path
request.fullpath
request.host
request.protocol

Example showing the difference

<ul>
  <li>URL: <%= request.url %></li>
  <li>Original URL: <%= request.original_url %></li>
  <li>Path: <%= request.path %></li>
  <li>Full path: <%= request.fullpath %></li>
  <li>Host: <%= request.host %></li>
  <li>Protocol: <%= request.protocol %></li>
</ul>

If the current page is:

https://example.com/shop/items?category=books

You would get roughly:

• request.url → https://example.com/shop/items?category=books
• request.original_url → https://example.com/shop/items?category=books
• request.path → /shop/items
• request.fullpath → /shop/items?category=books
• request.host → example.com
• request.protocol → https://

Rebuilding the URL manually

You could also combine parts yourself:

"#{request.protocol}#{request.host_with_port}#{request.fullpath}"

But in most cases, using request.url is simpler and clearer.

Consider this code in a Rails view:

<%= request.url %>

Suppose the browser visits:

https://myapp.com/articles/5?preview=true

Here is what happens step by step:

1. The browser sends a request to Rails for /articles/5?preview=true.
2. Rails builds a request object containing details about that HTTP request.
3. In the view, request is available automatically.
4. Calling request.url tells Rails to return the full absolute URL.
5. Rails combines the protocol, host, path, and query string.
6. The view outputs:

https://myapp.com/articles/5?preview=true

Step-by-step comparison

<p><%= request.path %></p>
<p><%= request.fullpath %></p>
<p><%= request.url %></p>

For the same request, Rails evaluates them like this:

1. request.path → /articles/5
2. request.fullpath → /articles/5?preview=true
3. request.url → https://myapp.com/articles/5?preview=true

This shows why request.request_uri or similar path-based methods are not enough when you need the absolute URL.

Getting the full current URL is useful in many real applications:

• Share links: show users the exact page URL to copy and share
• Return after login: remember where the user came from before authentication
• Analytics and tracking: log the exact page being viewed
• Webhook or callback setup: build links that must include the correct host and protocol
• Debugging: display the current request URL during development
• Canonical links: generate SEO-related page URLs when needed

Example: storing a return URL

session[:return_to] = request.url

Example: showing a share link in a view

<input type="text" value="<%= request.url %>" readonly>

Example: logging

Rails.logger.info("User visited: #{request.url}")

In real Rails codebases, developers often use request URL methods in a few common patterns.

Guard clauses and redirects

A controller may save the current URL before redirecting a user:

unless current_user
  session[:return_to] = request.url
  redirect_to login_path
end

This works well because the full URL can later be used to send the user back to the same page.

Validation and safety

Developers are careful when reusing URLs from requests, especially for redirects. A stored URL should be validated if there is any chance it came from user-controlled input.

redirect_to(session[:return_to] || root_path)

Logging and monitoring

Applications often include the current URL in logs or error reports:

Rails.logger.warn("Unexpected state at #{request.url}")

Building links with request data

Sometimes code needs only part of the URL, such as the host or protocol:

base_url = "#{request.protocol}#{request.host_with_port}"

This is common when generating absolute links in emails, APIs, or background jobs.

Choosing the right method

Experienced Rails developers usually choose the smallest useful piece of data:

• use request.path if only the path is needed
• use request.fullpath if query parameters matter
• use request.url if the complete absolute URL is required

That keeps code clearer and avoids accidental misuse.

A common beginner mistake is using a path-only method when a full URL is needed.

Mistake 1: Using request.path for a full URL

Broken example:

request.path

Output:

/products

Why it is wrong:

• It does not include protocol or host.
• It may not be enough for redirects, emails, or external links.

Use instead:

request.url

Mistake 2: Forgetting the query string

Broken example:

request.path

If the real page is:

https://example.com/search?q=rails

You lose ?q=rails.

Use instead:

request.fullpath   # relative with query string
request.url        # full absolute URL with query string

Mistake 3: Rebuilding URLs manually without the port

Broken example:

"#{request.protocol}#{request.host}#{request.fullpath}"

This may fail in development when the app runs on a custom port.

Safer version:

"#{request.protocol}#{request.host_with_port}#{request.fullpath}"

Or just use:

request.url

Mistake 4: Assuming all request methods mean the same thing

They do not. path, fullpath, url, and original_url return different values.

Mistake 5: Using request data in unsafe redirects

Be careful when redirecting to stored URLs. If the value is influenced by users, validate it before redirecting to avoid open redirect issues.

Here is a practical comparison of common Rails request URL methods:

request.url vs request.original_url

In many normal cases, these return the same value.

• request.url is the common direct choice for the current absolute URL.
• request.original_url emphasizes the original full URL of the request.

path vs fullpath

• path does not include query parameters.
• fullpath does include query parameters.

If your page uses filters, pagination, or search parameters, fullpath is often more useful than path.

# Full current absolute URL
request.url

# Full original URL
request.original_url

# Path only
request.path

# Path + query string
request.fullpath

# Host only
request.host

# Host with port
request.host_with_port

# Protocol only
request.protocol

Quick rules

• Use request.url when you need the full URL.
• Use request.path when you only need /some/path.
• Use request.fullpath when you need /some/path?x=1.
• Use request.host_with_port instead of request.host if the port matters.

Example

If the page is:

http://localhost:3000/posts/1?draft=true

Then:

request.url            # => "http://localhost:3000/posts/1?draft=true"
request.original_url   # => "http://localhost:3000/posts/1?draft=true"
request.path           # => "/posts/1"
request.fullpath       # => "/posts/1?draft=true"
request.host           # => "localhost"
request.host_with_port # => "localhost:3000"
request.protocol       # => "http://"

Best default answer

request.url

How do I get the current full URL in a Rails view?

Use:

request.url

What is the difference between request.path and request.url in Rails?

request.path returns only the path like /posts/1, while request.url returns the full absolute URL like https://example.com/posts/1.

Does request.url include query parameters?

Yes. If the current URL has a query string, request.url includes it.

When should I use request.original_url instead of request.url?

In many cases they are the same. request.original_url is useful when you specifically want the original complete request URL.

Why does request.request_uri not give the full URL?

Because it returns a relative form of the request location rather than the full absolute address with host and protocol.

Can I use request.url in both controllers and views?

Yes. The request object is available in both controllers and views in normal Rails usage.

How do I build the full URL manually in Rails?

You can do:

"#{request.protocol}#{request.host_with_port}#{request.fullpath}"

But request.url is usually simpler.

• request.path — related because it returns only the path part of the current request.
• request.fullpath — related because it includes the path and query string, but not the host.
• request.original_url — related because it returns the original full URL and is very close to request.url.
• Rails URL helpers — related because helpers like user_url and user_path generate URLs and paths.
• redirect_to — related because full URLs are often used when redirecting users.
• query parameters — related because they affect whether you should use path, fullpath, or url.
• request.host_with_port — related because it helps when building absolute URLs manually.
• HTTP request object — related because all these URL methods come from the request context.