Htaccess URL Rewrite Free Tool

Enter a URL

Eg. http://www.example.com/test.php?firstid=1&secondid=10

About Htaccess URL Rewrite

What This Tool Actually Does

The Htaccess URL Rewrite tool on this page takes one dynamic URL that carries a query string and turns it into two clean URL patterns with the Apache rewrite rules that make those patterns work. You paste a URL like http://www.example.com/test.php?firstid=1&secondid=10 into the single input field above, press the button, and the tool returns two text blocks. Each block contains a pretty URL and the RewriteRule line that maps that pretty URL back to the original script.

This is a narrow job.

The tool does not scan your website, does not fetch your pages, does not test whether your server supports mod_rewrite, and does not check whether the domain you entered even exists. It works entirely on the string you give it. The server-side code trims your input, lowercases it, strips off any http:// or https:// prefix, then adds http:// back on. That means a URL you enter with https:// will come back to you displayed as http://. The validation step uses PHP's FILTER_VALIDATE_URL, and if your input fails that check you'll see the message "Input Site is not valid!".

The tool only accepts dynamic URLs. If you enter a URL without a query string, meaning no ? followed by parameters, you get the error "URL entered does not seem to be a dynamic URL". A live test with http://www.example.com/page.html produced exactly that error. The tool needs the ?a=b structure to have anything to work with, because its entire purpose is converting query parameters into path segments.

What comes out the other side is a pair of rewrite rule sets. The first output style is called "Single Page URL", and it produces a flat filename with the parameters embedded. The second style is called "Directory Type URL", and it produces a path that looks like folders. Both styles are generated from the same input, so you get to see both options and choose the one that fits your site structure.

The rules themselves are written for Apache's mod_rewrite module. The output includes an Options +FollowSymLinks line and a RewriteEngine on line before each RewriteRule. The tool does not emit any flags like [L], [QSA], or [NC]. It does not generate redirects. It does not produce HTTPS forcing rules or www normalization rules. It produces internal rewrites only, and the rewrite rules are relative to the directory where your .htaccess file lives.

The whole operation happens without any network traffic to the domain you enter. The check runs entirely in the server-side PHP code on this page, so you can test URLs for sites you don't own without those sites ever seeing a request from you. That privacy property holds for every input you give the tool.

How to Use This Tool

1. Open the tool page. Find the input box above this article and make sure you have a dynamic URL ready.
2. Paste your dynamic URL. Enter a full URL that includes a query string, such as http://www.example.com/test.php?firstid=1&secondid=10. The placeholder text in the input box shows this exact format.
3. Submit the form. Click the button to send your URL to the tool. The page will reload and show you the generated output below the form.
4. Read both output blocks. You'll see the "Single Page URL" version and the "Directory Type URL" version, each with its own generated URL and RewriteRule lines.
5. Copy the block you want. Select the text from the textarea that matches the URL style you prefer for your site.
6. Create your .htaccess file. Place the copied code into a file named .htaccess and upload it to the same directory as your script. The tool notes that the file needs to be placed in the host directory that contains the script you're rewriting.

The form accepts a single URL in a single text field. There is no batch mode, no file upload, and no way to process a list of URLs in one request. Each submission handles exactly one dynamic URL and returns exactly two output blocks.

You can run the tool as many times as you need.

There is no CAPTCHA on this tool and no tool-specific request cap. A shared site-wide throttle applies to every page of this site, roughly fifteen requests within a single second from one visitor address blocks that address for the rest of the day. Normal use will never approach that limit. The output appears below the form after the page reloads. You'll see two labeled sections, each containing a textarea with the generated code. The rule text sits in a text box that you select and copy. The labels match the two style names exactly, making it easy to tell which block you're copying.

What the Generated Rules Include

The core of the tool's output is the RewriteRule line. Understanding what that line contains and what it omits will save you from surprises when you deploy the code on your own server. Each output block starts with Options +FollowSymLinks and RewriteEngine on. These two lines prepare Apache to process rewrite rules. The Options line enables symbolic link following, which many shared hosts require for mod_rewrite to function. The RewriteEngine on line activates the rewriting engine for the directory context.

The RewriteRule itself has three parts. The first part is the pattern, which matches the pretty URL. The second part is the substitution, which points to the original script with the query string reconstructed. The third part would be flags, but the tool emits none.

For the Single Page URL style, the pattern ends with \.htm$. The $ anchors the pattern to the end of the URL string, and the escaped dot matches a literal period before the .htm extension. The substitution rebuilds the query string using backreferences. For the input http://www.example.com/test.php?firstid=1&secondid=10, the rule becomes RewriteRule test-firstid-(.*)-secondid-(.*)\.htm$ test.php?firstid=$1&secondid=$2.

The Directory Type URL style produces two rule lines. One includes the trailing slash in the pattern, and one does not. For the same input, the rules become RewriteRule test/firstid/(.*)/secondid/(.*)/ test.php?firstid=$1&secondid=$2 and RewriteRule test/firstid/(.*)/secondid/(.*) test.php?firstid=$1&secondid=$2. The second line catches requests that omit the final slash.

The parameter order from your original query string is preserved in both output styles. The tool splits your query on & and then on =, keeping the key-value pairs in the order you provided them. The base name of your script, meaning the part before the first dot in the filename, becomes the stem of the pretty URL.

A live test produced the following results for the example URL from the placeholder text.

The second row comes from a second live test. The https:// prefix was converted to http:// in the output. The /catalog/ directory from the input URL does not appear in the rewrite rule pattern. The rule is relative, so it only matches the filename portion. This means your .htaccess file must sit in the same directory as your script for the rule to work.

The generated URL for the Single Page style follows a predictable formula. The base name comes first, then each key and value pair is appended with hyphens separating the parts. The whole thing ends with .htm. The Directory style puts the base name first as a folder, then each key as a subfolder, then each value as a subfolder under that, ending with a trailing slash.

Correcting the Old Description of This Tool

The previous version of this page described the tool in ways that do not match what the code actually produces. That older copy ran to roughly 2,100 words and made claims about features that simply are not present in the output. You get an exact description of the tool's capabilities.

The old description said the tool helps with forcing HTTPS. It does not. The generated rules contain no logic for redirecting HTTP traffic to HTTPS, no checks for the HTTPS environment variable, and no RewriteCond lines at all. The only protocol handling in the tool is the input normalization that converts your https:// prefix to http:// for display purposes. The old copy mentioned www and non-www normalization. The tool generates nothing of the sort. There are no rules that strip www from a domain or add it, no RewriteCond %{HTTP_HOST} lines, and no canonical host handling. The rewrite rules match only the path portion of the URL, never the hostname.

The old description referenced removing file extensions and trailing-slash rules. The tool does convert a .php extension into a .htm extension in the pretty URL, but it does not generate rules that strip extensions from arbitrary files. It produces no separate trailing-slash redirect rules beyond the paired Directory Type lines that handle the slash presence.

The old copy talked about legacy URL migration and choosing between permanent and temporary redirects. The tool generates no redirects whatsoever. Every rule it produces is an internal rewrite, meaning the browser's address bar keeps the pretty URL while the server internally maps it to the script. There is no [R] flag anywhere in the output, no status code selection, and no mechanism for telling search engines that a URL has moved.

The old description claimed the tool lets you "test a rewrite rule without risking my live site". The tool does not test anything. It does not fetch your site, does not validate that your script exists, does not simulate a request through Apache, and does not confirm that your server has mod_rewrite enabled. It performs string manipulation on the URL you provide and returns the resulting pattern.

The live tool behaves differently from the claims on the old page.

The real tool does one thing. It converts a single query-string URL into two pretty URL patterns plus the matching RewriteRule lines. That is the entire scope. If you need HTTPS forcing, www normalization, redirect management, or rule testing, you'll need to look at other tools or write those rules yourself.

The form accepts one URL per submission, and each submission returns output for that URL only. There is no queue, no history, and no saved state between visits. You'll need to run the tool once for each dynamic URL you want to convert.

The Two Output Styles Explained

The tool always produces two output blocks, and you should understand the difference before you copy either one into your .htaccess file. The two styles are not interchangeable in every situation, and each has strengths that suit different site architectures.

The Single Page URL style produces a URL that looks like a static HTML file.

For the example input, you get http://www.example.com/test-firstid-1-secondid-10.htm. This style is useful when you want each combination of parameters to appear as a distinct page with its own filename. Search engines treat .htm files as static content, which can be beneficial for indexing in some cases.

The Directory Type URL style produces a URL that looks like a folder path. For the same input, you get http://www.example.com/test/firstid/1/secondid/10/. This style is useful when you want a hierarchical structure that suggests parent-child relationships between content. The trailing slash mimics the convention of directory indexes.

Both styles use the same underlying mechanism. The RewriteRule pattern captures the parameter values using (.*) groups, and the substitution places those captured values back into the query string. The difference is purely cosmetic in how the URL appears to the visitor and to search engines.

The tool names the first style "Single Page URL" and the second "Directory Type URL" in its output. Each block is shown in a textarea with the note "Create a .htaccess file with the code below" and a reminder that the file needs to be placed in the host directory. You can copy either block independently, or you can use both if you want to support both URL formats for the same content.

The tool derives the base name from the last path segment of your input URL. For test.php, the base name is test, which comes from the part before the first dot. For item.php, the base name is item. The file extension is discarded entirely and replaced with .htm in the Single Page style or with a directory structure in the Directory style. The query parameter names become part of the URL structure. In the Single Page style, the parameter names appear literally in the filename. In the Directory style, the parameter names become folder names. This means your URL structure exposes your parameter naming scheme to visitors, which is fine for simple cases but worth considering if your parameter names are cryptic or internal.

Limitations of the Generated Rules

The rules this tool produces are functional for basic cases, but they carry real technical limitations that come directly from the code's output format. Knowing these limits before you deploy will prevent confusing behaviour later.

The capture groups use (.*), which is greedy. A greedy pattern matches as much as possible, and with two greedy groups in one pattern, the split between them can be ambiguous. In the Single Page style, if your parameter values contain hyphens, Apache may split the captured value at the wrong hyphen. In the Directory style, if your values contain slashes, the pattern can capture across directory boundaries in unexpected ways. There is no ^ start anchor in either pattern. The Single Page pattern does end with $, which anchors the end, but the beginning of the pattern is not anchored to the start of the URL path. The Directory patterns have neither anchor. In practice, this means the rules could match URLs that have unexpected prefixes, though the relative nature of the rules limits the practical impact.

No flags are emitted. The absence of [L] means Apache will continue processing subsequent rules after a match, which can cause unexpected behaviour if you have other rules in the same .htaccess file. The absence of [QSA] means any extra query parameters on the pretty URL will be dropped when the rewrite happens. If a visitor appends ?utm_source=google to your pretty URL, that parameter will not reach your script.

The Options +FollowSymLinks line can cause problems on some shared hosts. Many hosting providers disable the Options directive in .htaccess files for security reasons, and including it can trigger a 500 Internal Server Error. Some hosts require +SymLinksIfOwnerMatch instead. If you see a 500 error after uploading the generated code, this line is the first thing to remove or modify.

The rules are relative to the directory containing the .htaccess file. The live test with https://shop.example.org/catalog/item.php?id=42 produced a rule that matches item-id-(.*)\.htm$ without any reference to the /catalog/ directory. If you place the .htaccess file in your document root instead of the /catalog/ directory, the rule will not match anything.

The tool generates rewrites. This distinction matters for search engine optimisation. When a rewrite happens, the browser's address bar keeps the pretty URL, and the server internally serves the content from the script. Search engines that discover the old query-string URL will continue to see that URL as the canonical version unless you also add redirects or canonical tags pointing to the pretty version.

The main limitations require planning.

The tool does not check whether your server runs Apache. Nginx and IIS do not read .htaccess files at all. LiteSpeed and OpenLiteSpeed do read them, since those servers implement Apache-compatible rewrite syntax. If you're on Nginx, you'll need to translate these rules into try_files or rewrite directives in your server block configuration.

The greedy capture issue deserves extra attention. Consider a value like product-123 in a Single Page URL. The pattern test-firstid-(.*)-secondid-(.*)\.htm$ will try to match as much as possible in the first group, potentially pushing part of the value into the second group. Testing with your actual data is the only way to know whether the split lands where you expect.

How the Tool Processes Your URL

The server-side logic follows a straightforward sequence. Understanding this sequence helps you predict what the tool will do with any URL you enter, including edge cases that might surprise you.

First, the input is trimmed of whitespace and lowercased. This means HTTP://WWW.Example.COM/Test.PHP?ID=5 becomes http://www.example.com/test.php?id=5 before any further processing. The lowercasing applies to the entire URL, including the path and query parameter names, which can matter if your server uses case-sensitive filenames.

Second, any http:// or https:// prefix is stripped off, and then http:// is added back. This is why an https:// input URL appears as http:// in the output. The tool does not preserve the original protocol, and it does not generate any rules that would affect protocol handling.

Third, the URL is validated with FILTER_VALIDATE_URL. If validation fails, you see "Input Site is not valid!". This validation checks the overall URL structure, not whether the domain exists or whether the page is reachable.

Fourth, the tool checks whether the URL contains a query string.

The check looks for the ? character followed by key-value pairs. If there is no query string, you see "URL entered does not seem to be a dynamic URL". This check is what makes the tool refuse to process static URLs like http://www.example.com/page.html. Fifth, the tool splits the URL into its components. The last path segment becomes the filename. The part of that filename before the first dot becomes the base name. The query string is split on & to separate parameters, and each parameter is split on = to separate the key from the value.

Sixth, the tool builds the two output styles from these components. The parameter order is preserved exactly as you entered them. If your query string has firstid=1&secondid=10, the output will always have firstid before secondid, never the reverse.

The tool makes no external requests during this process. It does not ping your domain, does not check DNS records, and does not verify that your script exists on your server. The entire operation happens in memory on this site's server.

The lowercasing step deserves special attention. If your script filenames are case-sensitive, as they are on most Linux servers, a URL like MyPage.PHP will be lowercased to mypage.php before the base name is extracted. The resulting rule will reference the lowercase name, which may not match the actual file on your server.

What the Tool Does Not Do

The scope of this tool is deliberately narrow, and the old page description inflated that scope considerably. This section lists the operations the tool does not perform, so you can plan your workflow accordingly.

The tool does not generate redirect rules. Every output line is a rewrite, meaning the server internally maps the pretty URL to the script without telling the browser anything has changed. If you want old URLs to redirect to new ones, you need a different tool or manual rule writing. The tool does not handle HTTPS. It will not generate rules that force secure connections, and it will not preserve the https:// protocol in its output URLs. The input normalization converts HTTPS to HTTP for display, which is a cosmetic transformation only.

The tool does not handle www versus non-www. It generates no rules that reference the hostname at all. If you want to canonicalize your domain to one form, you need separate rules that use RewriteCond with %{HTTP_HOST}.

The tool does not test anything. It does not verify that your server supports mod_rewrite, does not check whether the .htaccess file syntax is valid for your server, and does not simulate a request to see if the rule matches. The output is purely a text transformation of your input.

The tool does not generate rules for removing file extensions from existing static pages. It only converts the one script you provide into a .htm pretty URL. If you have a site full of .php files and want all of them to appear as .htm, this tool will not do that in one pass.

The tool does not handle multiple URLs at once. The form accepts a single URL in a single text field. There is no batch mode, no file upload, and no way to process a list of URLs in one request.

The tool does not generate RewriteCond lines. Every rule it produces is a simple pattern-to-substitution mapping with no conditions attached. If you need rules that only apply under certain circumstances, such as for specific browsers or specific request methods, you'll need to add those conditions yourself.

The tool also does not validate that your query string follows any particular format. It will happily process a URL with empty values or missing keys. The output will reflect whatever structure you provide, even if that structure produces rules that don't make sense for your application.

The Rewrite Versus Redirect Distinction

The difference between a rewrite and a redirect is central to understanding what this tool produces. The old page blurred this distinction, and correcting it matters for anyone using the output for search engine optimisation.

A rewrite is an internal server operation.

When Apache processes a rewrite, it changes the URL that the server uses to find the content, but the browser never learns about this change. The address bar in Chrome, Firefox, or Safari continues to show the pretty URL. The server internally maps that pretty URL to your script and serves the response.

A redirect is an external operation. When Apache processes a redirect, it sends an HTTP response with a status code like 301 or 302, telling the browser to request a different URL. The browser then makes a second request to the new URL, and the address bar updates to show the destination.

This tool generates rewrites only. The generated rules contain no [R] flag, which is the flag that would turn a rewrite into a redirect. The absence of this flag means the browser never sees a redirect response, and the old query-string URL remains accessible and unchanged.

For search engine optimisation, this distinction has practical consequences. When a search engine crawler discovers your old query-string URL, it will fetch that URL and see the content. It will not automatically learn that the pretty URL is the canonical version, because the server does not send a redirect from the old URL to the pretty URL.

To make the pretty URL canonical, you need to do additional work. You can add a canonical link tag to your pages pointing at the pretty URL. You can also add your own redirect rules that send visitors and crawlers from the old query-string URL to the pretty URL. The tool provides none of this. The rewrite approach does have one advantage. Old URLs keep working without any extra configuration. If someone has bookmarked your query-string URL or shared it on social media, that URL will continue to serve content. You don't need to worry about broken links during a transition period.

Practical Deployment Advice

When you take the output from this tool and deploy it on your server, a few practical steps will save you from common problems. The tool's output is a starting point for your own configuration work.

Place the .htaccess file in the correct directory.

The rewrite rules are relative, meaning they match URLs relative to the directory containing the file. If your script lives at /catalog/item.php, place the .htaccess file in the /catalog/ directory. The live test with the /catalog/ path produced a rule that does not include that directory in the pattern, confirming this requirement. Test on a staging server first if you have one. The tool does not test the rules, so you should verify the behaviour in an environment where a mistake won't take down your live site. A 500 error from the Options line is the most likely failure, and you can catch that on staging.

Check whether your host allows Options overrides. Many shared hosts disable this directive in .htaccess files. If you get a 500 error, remove the Options +FollowSymLinks line or replace it with Options +SymLinksIfOwnerMatch if your host requires that form.

Consider adding flags manually. The tool emits no flags, but you may want to add [L] to stop rule processing after a match. If you have other rewrite rules in the same file, the absence of [L] can cause unexpected interactions.

Think about whether you need [QSA]. If visitors might append query parameters to your pretty URLs, such as tracking parameters from marketing campaigns, you'll want to add [QSA] so those parameters are appended to the rewritten query string. Without it, those parameters are silently dropped.

Verify that your server runs Apache or LiteSpeed. Nginx and IIS do not process .htaccess files. If you're on Nginx, you'll need to translate the rules into Nginx's rewrite directive syntax, which is a different format.

Back up your existing .htaccess file before making changes. If you already have rules in place, adding new ones without understanding the interactions can break existing functionality. Keep a copy of the original file so you can restore it quickly if something goes wrong.

When to Use Each Output Style

The choice between the Single Page URL style and the Directory Type URL style depends on your content structure and your preferences for URL aesthetics. Both styles work with the same underlying mechanism, so the decision is mostly about how you want your URLs to look.

The Single Page style produces URLs that end in .htm. This style mimics static HTML files, which some site owners prefer because it suggests stable, unchanging content. Search engines have historically treated static-looking URLs favourably, though modern crawlers handle both styles equally well.

The Directory style produces URLs that end in a trailing slash. This style mimics directory structures, which can suggest a hierarchy of content. If your site has natural categories and subcategories, the Directory style can mirror that structure in the URL path.

Consider how your parameter values look. If your values are short identifiers like numeric IDs, both styles work cleanly. If your values are long text strings with spaces or special characters, the Single Page style can produce very long filenames, while the Directory style spreads the length across path segments. Consider how your parameter names read. The tool inserts parameter names directly into the URL. If your parameter names are meaningful words like category and product, the resulting URL reads naturally. If your parameter names are cryptic abbreviations like ct and pr, the URL will look less appealing.

Here is a quick comparison of when each style might fit your needs.

You can also use both styles simultaneously. The tool generates both outputs for every input, and nothing stops you from placing both rule sets in your .htaccess file. This approach supports both URL formats, though it doubles the number of rules and increases the chance of pattern conflicts.

The length of your URLs matters for practical reasons. Very long URLs can be truncated in some email clients and social media platforms. If your parameter values are lengthy, the Directory style tends to produce URLs that are easier to share, since the length is distributed across multiple path segments rather than concentrated in a single filename.

Related Tools

If you need to send visitors and search engines from old URLs to new ones, the Htaccess Redirect Generator will create the redirect rules this tool does not produce.

To check whether your site already redirects between www and non-www versions of your domain, the www Redirect Checker will test your live configuration.

To control which pages search engines should crawl on your site, the Robots.txt Generator builds a robots.txt file that works alongside your rewrite rules.

Frequently Asked Questions

Does this tool work for HTTPS URLs?

The tool accepts HTTPS URLs as input, but it converts the protocol to HTTP in its output. The generated rewrite rules do not reference the protocol at all, so they work the same regardless of whether your site uses HTTP or HTTPS. If you need to force HTTPS or redirect HTTP to HTTPS, you'll need separate rules that this tool does not generate.

Why does the tool reject my URL without a query string?

The tool is designed specifically to convert dynamic URLs with query strings into clean URLs. If your URL has no ? followed by parameters, there is nothing for the tool to convert. The error message "URL entered does not seem to be a dynamic URL" tells you that the input lacks the query string structure the tool requires.

Will these rules work on Nginx or IIS?

No. The generated rules use Apache mod_rewrite syntax, which only Apache and Apache-compatible servers like LiteSpeed and OpenLiteSpeed understand. Nginx uses its own rewrite directive syntax, and IIS uses URL Rewrite module rules with a different format. You'll need to translate the rules manually if you run either of those servers.

Why does my site return a 500 error after I add the code?

The most likely cause is the Options +FollowSymLinks line. Many shared hosts disable the Options directive in .htaccess files for security reasons. Remove that line or replace it with Options +SymLinksIfOwnerMatch if your host requires that form. Also check that the .htaccess file is in the same directory as your script, since the rules are relative.

Does the tool test whether my rewrite rule works?

No. The tool performs string manipulation on the URL you provide and returns the resulting pattern. It does not fetch your site, does not verify that your script exists, and does not simulate a request through Apache. You should test the generated rules on a staging server or in a development environment before deploying to your live site.

Can I use these rules to redirect old URLs to new ones?

No. The tool generates internal rewrites. A rewrite keeps the pretty URL in the browser's address bar while the server internally maps it to your script. The old query-string URL remains accessible, and search engines will not automatically treat the pretty URL as canonical. For redirects, use the Htaccess Redirect Generator or write [R=301] rules yourself.