The Trailing Slash Question: A Practical Breakdown

Should a URL end with a slash or not? It's a small character with outsized implications, and the choice often comes down to how your site is built and hosted. The core difference: https://example.com/resource/ has a trailing slash, while https://example.com/resource does not.

One common convention is to reserve the trailing slash for pages that act as directories—those with child pages or a distinct landing purpose—and to omit it for leaf pages that are the end of the content line. In practice, however, many systems defy this. For instance, WordPress blogs commonly append a trailing slash to individual posts and will issue a redirect if you omit it.

That redirect is precisely where the performance concern lives. Every redirect adds a round trip, so you want to minimize how often a visitor triggers one. But the stakes are higher than a small delay. Duplicate content is another issue: if your server renders the same page at both the slashed and unslashed URLs, you risk a duplicate-content penalty, even if search engines might realistically be smart enough to handle it.

The most damaging technical pitfall, though, is resource resolution. As Zach Leatherman points out, relative resource URLs behave very differently based on the trailing slash:

If you're using relative resource URLs, the assets may be missing on Vercel, Render, and Azure Static Web Apps (depending on which duplicated endpoint you've visited).

<img src="image.avif"> on /resource/ resolves to /resource/image.avif

<img src="image.avif"> on /resource resolves to /image.avif

This is not a trivial difference. A single misplaced slash can result in a page serving broken images or stylesheets, which is reason enough to justify a redirect that consolidates traffic to one canonical form.

Complicating matters further, your static site generator and your hosting provider may have their own preferences. There are known disagreements among hosts about which URL form should be canonical, so this is not always a decision you can make in a vacuum. The pragmatic path is to go with the grain: wherever your framework and platform naturally point, follow it, as long as you have the necessary redirects in place and don't have to override a bunch of configuration to make it work.