Free tools Windows power users keep installed
One-click scans. No signup required.
To remove WordPress’ common ?ver= parameter from frontend CSS and JavaScript, either enqueue each asset with a null version or remove only the ver argument through the style and script loader filters. Do not strip query strings indiscriminately: they are cache-busting signals, and removing them without another invalidation method can leave visitors using stale files.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The practical sequence is to limit the change to local static assets, preserve parameters used by third parties, purge every relevant cache, and verify that an edited stylesheet or script is delivered to a fresh browser. A cleaner URL alone does not guarantee a measurable speed or SEO improvement.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →What a query string is doing on a WordPress asset
A URL such as /wp-content/themes/example/style.css?ver=6.6 has a query string after the question mark. WordPress commonly adds ver when a stylesheet or script is registered or enqueued with a version. If the version argument is false, WordPress uses the installed WordPress version. The wp_enqueue_style() reference describes the value as a stylesheet version added to the URL “for cache busting purposes”; the script registration API documents the same behavior for JavaScript.
Browsers, reverse proxies and CDNs may include the query string when they create a cache key. When the version changes, the URL appears different and a new copy can be fetched. Removing the parameter can make cache keys simpler on a particular stack, but it also removes that invalidation signal. The change is therefore a cache-policy decision, not merely a cosmetic URL cleanup.
#1 Best Overall
When leaving ?ver= is the better choice
- Your deployment already changes the version whenever a file changes.
- Your CDN or page-cache rules treat query strings correctly and audits show no meaningful penalty.
- You cannot reliably purge browser, proxy and CDN caches after an asset deployment.
- A plugin or theme depends on a query argument other than
ver.
When removal can be reasonable
- Your cache layer creates an unwanted variant for every version value.
- You have filename-based revisioning, a dependable deployment purge, or another explicit invalidation process.
- You have measured the site and confirmed that the existing cache-key behavior is causing a real problem.
Autoptimize’s documentation notes that the measured effect of removing ver can be little or none. Treat any improvement as site-specific and report your own before-and-after measurements rather than promising a universal percentage.
Method 1: omit the version in the enqueue call
If you control the theme or plugin code that enqueues the asset, this is the narrowest approach. Pass null as the version argument. WordPress documents null as the value that intentionally prevents the version query string.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallwp_enqueue_style(
'site-style',
get_stylesheet_uri(),
array(),
null
);
wp_enqueue_script(
'site-script',
get_template_directory_uri() . '/assets/site.js',
array(),
null,
true
);The stylesheet call uses the theme’s stylesheet URI. The script call loads assets/site.js and places it in the footer because its final argument is true. Keep the dependency arrays and loading position appropriate for your project; changing them is unrelated to query-string removal.
Build an invalidation plan first
With null, a changed file can retain the same URL. Choose one replacement before deploying:
- Rename or fingerprint files during your build, for example by producing a new filename when the contents change.
- Purge the page cache, object cache, browser-facing cache and CDN after each asset deployment.
- Use a cache layer that generates revisioned static filenames.
If none of these is dependable, leave versioning enabled. A stale but syntactically clean stylesheet is worse than a URL containing ?ver=.
Method 2: remove only ver with WordPress filters
When a theme or plugin enqueues files you do not want to edit, filter the final URLs generated for frontend styles and scripts. The usual production pattern is:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesfunction mytheme_remove_ver_query_arg( $src ) {
if ( is_admin() ) {
return $src;
}
return remove_query_arg( 'ver', $src );
}
add_filter( 'style_loader_src', 'mytheme_remove_ver_query_arg', 10, 1 );
add_filter( 'script_loader_src', 'mytheme_remove_ver_query_arg', 10, 1 );style_loader_src receives the fully qualified stylesheet URL; script_loader_src is the analogous script hook. The is_admin() check keeps the administrative interface out of the change. Place the function in a site-specific plugin or a child theme rather than editing a parent theme that will be replaced during an update.
Why the explicit argument matters
remove_query_arg() removes the key you name and leaves other keys in place. The function’s return value is not escaped by default, so escape a URL if you print the returned value in markup that you generate yourself. WordPress’ own enqueue pipeline handles its normal output escaping; custom HTML must still follow normal escaping rules.
Avoid the common no-op implementation
Do not pass an empty or incorrectly derived key list to remove_query_arg(). Code that parses a URL and then supplies no explicit argument can silently remove nothing. It can also become unsafe if it assumes every URL has the same structure. For the normal WordPress parameter, naming ver directly is clearer and easier to test.
Use a local-asset guard for mixed or third-party pages
A broad filter can touch URLs that should not be modified. External services may require signed parameters, cache tokens or API options. A stricter callback checks the host and file extension before removing ver:
function mytheme_remove_ver_from_local_assets( $src ) {
if ( is_admin() ) {
return $src;
}
$parts = wp_parse_url( $src );
$path = isset( $parts['path'] ) ? $parts['path'] : '';
if ( $path === '' ) {
return $src;
}
$asset_host = isset( $parts['host'] ) ? strtolower( $parts['host'] ) : '';
$site_host = strtolower( (string) wp_parse_url( home_url( '/' ), PHP_URL_HOST ) );
if ( $asset_host !== '' && $site_host !== '' && $asset_host !== $site_host ) {
return $src;
}
$extension = strtolower( pathinfo( $path, PATHINFO_EXTENSION ) );
if ( ! in_array( $extension, array( 'css', 'js' ), true ) ) {
return $src;
}
return remove_query_arg( 'ver', $src );
}
add_filter( 'style_loader_src', 'mytheme_remove_ver_from_local_assets', 10, 1 );
add_filter( 'script_loader_src', 'mytheme_remove_ver_from_local_assets', 10, 1 );This callback permits relative URLs and URLs on the site’s own host, then limits the operation to paths ending in .css or .js. It leaves a different host untouched. If your site deliberately serves assets from a separate first-party CDN hostname, add that hostname to an allowlist rather than weakening the check for every external URL.
Parameters you should preserve
The callback removes only ver. A URL such as theme.css?ver=12&rtl=1 retains rtl=1. That is important because parameters can select language, direction, a signed request or another functional variant. Never replace this targeted operation with code that deletes every query argument from every URL.
Method 3: use a plugin or cache layer
Site owners who do not write PHP can use a WordPress.org plugin that applies equivalent frontend filters. “WP Remove Query Strings From Static Resources” describes targeting local CSS and JavaScript while ignoring external resources. InfoBilisim’s plugin offers similar behavior and an exclusion hook. Before enabling either, check its current update activity, compatibility with your WordPress and PHP versions, exclusion controls, and how to disable it if a page breaks.
A cache plugin can expose a related setting. LiteSpeed Cache documentation describes controls that affect how query strings are handled for CSS and JavaScript enqueued by WordPress, while skipping external URLs and selected exclusions. Such a setting can change cache variants without rewriting the HTML URL itself.
Do not confuse asset URLs with page-cache keys
Some cache interfaces also offer to ignore query strings when caching complete pages. That is a different operation. Tracking parameters, product filters, search terms, preview flags and signed URLs can change page output. Dropping those parameters from a page-cache key can serve one visitor’s response to another or show the wrong filtered result. Configure page-cache handling separately from removing ver on static assets, and document each rule.
Rank #4
Choosing an approach
| Approach | Scope | Exclusions | Required invalidation | Rollback | What it changes |
|---|---|---|---|---|---|
null in one enqueue call |
One stylesheet or script you control | Handled directly in that call | Filename revisioning or a reliable purge | Remove null or restore the previous version |
That asset URL only |
| Basic loader filters | All frontend styles and scripts passing through the hooks | Admin pages are excluded; other URLs need additional checks | Same as above, for every affected asset | Disable the function and clear caches | Frontend asset URLs |
| Local-only loader filters | Local paths ending in .css or .js |
Different hosts and other extensions are preserved | Same as above, with fewer third-party risks | Disable the function and clear caches | Selected frontend asset URLs |
| Plugin or cache setting | Defined by its implementation and exclusions | UI exclusions, allowlists or hooks vary | Follow the plugin or cache layer’s purge process | Disable the setting or plugin, then purge | Asset URLs, and possibly cache-variant behavior |
The local-only filter is generally the safest global choice when you must affect assets you do not control. The enqueue change has the smallest blast radius. A plugin is convenient, but its defaults and update status become part of your site’s dependency chain.
Safe implementation procedure
- Record the current behavior. Open a logged-out page, view its rendered HTML, and list the local CSS and JavaScript URLs containing
?ver=. Note third-party scripts separately. - Identify ownership. If your theme or plugin creates the enqueue call, prefer the
nullargument. If several components create the URLs, use a targeted filter or a maintained plugin. - Choose invalidation. Confirm filename revisioning or write down the exact page, object, browser and CDN purge steps that will follow every asset deployment.
- Apply the smallest change. Start with one enqueue call or a staging copy. If using a filter, keep the administrator exclusion and the local CSS/JS checks.
- Clear caches. Purge page and object caches, the CDN or reverse proxy, and any optimization-plugin cache. A browser may still hold an old response, so test in a private window or with a fresh profile.
- Inspect the output. Confirm that intended local URLs no longer contain
ver, while external resources and functional parameters remain unchanged. - Test both session states. Check logged-out and logged-in views, responsive layouts, authenticated screens that are meant to remain unaffected, and pages with third-party embeds.
- Test a real asset change. Alter a harmless CSS declaration or script comment in staging, deploy it, purge according to your plan, and verify that a fresh browser receives the new content.
- Measure after the cache is warm. Re-run the same performance audit and compare the request waterfall, cache status and transfer behavior. Keep the change only if it solves an observed problem without introducing stale assets or broken dependencies.
Cache invalidation options after removal
Filename-based revisioning
A build process can emit a new filename when file contents change, such as a content-hashed stylesheet. Every reference then points to a new URL, so the cache can retain old files safely while clients request the new name. Ensure the HTML or manifest that references the filename is itself purged or regenerated.
Deployment purges
If filenames remain stable, make cache purging a deployment step. Include the CDN, reverse proxy, full-page cache and any persistent object or optimization cache in the runbook. Browser caches cannot be centrally purged in the same way, so stable filenames require cache headers and a process that tolerates clients holding an older copy.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Generated static asset names
Some optimization systems generate revisioned files when they combine or minify CSS and JavaScript. In that setup, removing WordPress’ ver can be safe only if the generated filename changes whenever the source changes and the generated-file cache is purged.
Troubleshooting
The query string is still present
- Confirm the code runs on the frontend and is loaded before the enqueue output is generated.
- Check whether the URL is produced by markup outside the WordPress loader hooks.
- Inspect the actual parameter name. A plugin may use a token other than
ver. - Purge cached HTML; you may be viewing an older page containing the previous URL.
Styles or scripts are stale after an update
Restore versioning or immediately use the missing purge or filename-revision step. Do not solve stale files by deleting more query arguments. Verify the response headers and the asset body in a fresh browser, then update the deployment runbook.
Best Value
A third-party integration stopped working
Revert the broad filter and switch to a local-host and .css/.js allowlist. Inspect the affected URL for signed, token or configuration parameters. Preserve the entire external URL unless the service documentation explicitly permits changing it.
The admin area changed unexpectedly
Ensure the callback returns immediately when is_admin() is true. Also check whether a frontend request is being made through an administrative endpoint; exclude that specific path rather than removing the administrator guard.
Recommended Free Tools
The performance score did not move
That result is normal. Query-string handling is only one cache-key detail. Network latency, compression, render-blocking resources, cache headers, script execution and the CDN’s policy may dominate the waterfall. Keep the change only when your measurements show a concrete benefit or it simplifies a documented cache policy without harming freshness.
Security and compatibility checklist
- Limit global filters to the frontend unless you have a reason to alter administrative assets.
- Target local static CSS and JavaScript rather than every URL.
- Preserve parameters required by third-party services, signed requests and dynamic resources.
- Use a site-specific plugin or child theme so an update does not erase the change.
- Escape URLs returned by query-argument helpers when outputting custom markup.
- Document the replacement cache-busting method and its rollback procedure.
- Test after WordPress, theme, plugin, CDN or cache-layer updates because any of them can change how assets are generated.
What this change can and cannot promise
Removing ?ver= can reduce unnecessary cache variants on a particular configuration and produce cleaner-looking static URLs. It cannot guarantee faster loading, a higher audit score, improved search ranking or fewer requests. The result depends on cache headers, CDN behavior, asset revisioning, deployment discipline and the site’s actual request waterfall.
For most sites, the defensible rule is simple: remove only the specific ver parameter from local frontend CSS and JavaScript when you have another reliable way to invalidate changed files. Otherwise, keep WordPress’ built-in cache-busting behavior and address the cache configuration that is creating the reported warning.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
