WordPress plugin_dir_url Example: Build Plugin Asset URLs Correctly
A clean plugin development guide to generating asset URLs correctly with plugin_dir_url instead of mixing filesystem and browser paths.
Published
May 8, 2026
Reading Time
2 min read
Updated
May 8, 2026

Implementation Notes
Extension points, code paths, and implementation choices that should survive contact with production.
Best For
WordPress developers, agencies, and technical teams building custom plugin or theme functionality with cleaner operational defaults.
Primary Topics
Editorial Focus
Build Pattern: Extension points, code paths, and implementation choices that should survive contact with production. Updated on May 8, 2026.
Full Report
Last reviewed: May 8, 2026
Plugin code often gets asset URLs wrong in subtle ways. Developers use filesystem paths where a browser URL is needed, concatenate hosts manually, or assume every file lives in the plugin root. plugin_dir_url() solves the URL half of that problem by returning the directory URL for the file you pass into it, with a trailing slash already included.
This guide shows how to use plugin_dir_url() correctly for CSS, JavaScript, and image assets without mixing it up with filesystem helpers.
Use it when the browser needs a plugin-owned asset URL
<?php
wp_enqueue_style(
'vulnwp-admin',
plugin_dir_url( __FILE__ ) . 'assets/admin.css',
array(),
'1.0.0'
);
This is the right mental model: plugin_dir_url() for URLs, plugin_dir_path() for filesystem paths.
Pass the correct file reference for the directory you actually want
The helper returns the directory URL of the file you give it. That means nested include files can point to a deeper directory than the plugin root if the code uses __FILE__ blindly from the wrong location. When the asset path should be rooted higher, the passed file reference needs to reflect that.
Do not treat URL helpers like include-path helpers
A URL string can be perfect for the browser and useless for require_once. Keeping those two concerns separated makes plugin code easier to reason about and less fragile during path refactors.
Common mistakes
- Using
plugin_dir_path()for browser assets. That returns a filesystem path, not a URL. - Using the wrong
__FILE__context in nested directories. The base can shift deeper than intended. - Hardcoding
wp-content/plugins. WordPress installations are not required to keep that layout. - Skipping
esc_url()when rendering the final URL into markup. URL generation and output escaping are different steps.
Production checklist
- Use
plugin_dir_url()for plugin CSS, JS, and image URLs. - Use
plugin_dir_path()for includes and local filesystem work. - Review nested files so the base file reference points to the intended directory.
- Avoid hardcoded plugin directory assumptions.
- Escape rendered asset URLs in markup output.
Related reading
Pair this with the plugin_dir_path guide for filesystem usage, and with the wp_enqueue_script article when the asset URL is headed into front-end or admin enqueues.


