Comparing server-side and client-side paywall technology

By Jack Marshall • September 3, 2021

There are effectively two methods for paywalling web-based content from a technical perspective: Server-side, and client/browser-side.
Each approach has advantages and drawbacks which should be understood and weighed when determining which to employ.

One important challenge for any publisher selling access to content on a subscription or membership basis is how best to ensure it’s only made available to paying customers. No publisher likes the idea of visitors “hacking” their way around a paywall to access premium content for free.

The vast majority of publishers and paywall technology providers currently employ one of two technical approaches to paywalling web-based content: the “server-side” method, or the “client-side” method. (The client-side method is also referred to as “browser-side”)

Each approach comes with its own set of advantages and drawbacks, which should be understood and evaluated to determine which is best for a product based on goals, content, business model and other variables.

The following is a simplified guide to client-side and server-side method and the pros and cons of each. It’s designed to help inform strategic and tactical decisions around which method to employ; not to give a detailed technical breakdown of how each functions. “Paywalling” content is also a vague term encompassing many elements. Some may instead refer to protecting content, locking content, restricting access, access control, permission checking, etc. This guide will refer simply to paywalling content.

What are client-side and server-side paywalls?

Both server-side and client-side approaches can be used to hide content from website visitors, but each achieves that outcome differently and with different results:

Client-side paywalls

When a visitor attempts to access a piece of paywalled content from a site with a client-side paywall, the site will do the following, in order:

Deliver paywalled content in its entirety to the visitor’s browser.
Check if the visitor has permission to view the content.
Hide paywalled content from the view if the visitor doesn’t have permission to view it.

With this method, the full paywalled content typically exists in the underlying HTML of the webpage whether the visitor has permission to view it or not. In some instances paywalled content will be visible for a second or two before a site has time to check a visitor’s permissions (typically using javascript) and subsequently attempts to hide it.

Server-side paywalls

Sites with server-side paywalls do things a little differently. When a reader attempts to access a piece of paywalled content, the site will:

Check first to establish if the visitor has permission to view the content.
Deliver paywalled content to the visitor’s browser only if they have permission to view it.

The server-side method is often considered more secure because paywalled content is only delivered to those visitors who have permission to view it, and is not present in a webpage’s underlying HTML for those who don’t.

Drawbacks of client-side paywalls

Client-side paywall implementations have two key considerations and potential drawbacks to take into account: Content security, and site performance and user experience.

Content security

The primary drawback or “risk” of client-side content protection is simple: One way or another, visitors will technically be able to gain access to paywalled content without signing in and/or paying for access to it.

Getting around client-side paywalls is easier in some instances than others, depending on how a site has implemented them. In some cases visitors can simply view the source code of the page — accessible via a simple right mouse click in Google’s Chrome browser — to unveil the paywalled content embedded in a page’s raw HTML. In other instances, gaining access to paywalled content is significantly harder and requires more detailed technical knowledge or multi-step processes on the user’s part, such as disabling javascript.

A simple Google search will surface posts and videos describing how to circumvent client-side paywalls on many popular sites, and browser plugins and other software designed to help users get around paywalls are also available. Some publishers intermittently change their paywall implementations in an effort to temporarily combat and mitigate the efficacy of these tactics, but user interest in bypassing paywalls continues to grow.

Site performance and user experience

The second key consideration and potential drawback of client-side paywalls relates to performance and user experience. Owing to the fact that content must typically be loaded fully (including paywall-related javascript) before decisions about content blocking or access control can be made, client-side paywalls can result in slower page load times and an arguably inferior user experience.

User experience: It’s not uncommon for pages to shift around as client-side paywall elements load, or for content to be visible for a period of time before it’s hidden from a visitor’s view. This can create the impression that a site is unstable, or that the content isn’t fully locked away and beyond the reach of non-paying users. As a result, some publishers may conclude that a server-side paywall implementation can provide a more seamless experience.

Site performance: Client-side implementations can contribute to significantly longer page load times and unstable pages, both of which raise potential search engine optimization (SEO) concerns. Google, for example, factors in site performance to its ranking algorithm, and the introduction of its page experience update in June of 2021 has added additional search engine optimization considerations for subscription publishers in the form of “Core Web Vitals”. Hiding content or moving it around pages with client-side paywall implementations can contribute to poor Core Web Vitals scores, which may in turn result in lower search rankings and a reduction in organic search traffic.

Advantages of client-side paywalls

Despite the potential content security risks outlined above, blocking content at the browser-level means that client-side implementations can offer a range of advantages over server-side ones:

Ease of implementation

Client-side paywalls can typically be implemented relatively easily. Tools provided by some paywall technology providers, for example, can make instituting a paywall as simple as adding javascript to a site and setting up some basic access rules within their platforms. For this reason, client-side approaches are sometimes favored by publishers with fewer technical and financial resources, or those looking to stand up paid content products quickly. Server-side methods, by contrast, can require greater technical input to implement effectively.

Greater flexibility and control

Client-side approaches can provide greater flexibility for controlling a paywall setup without significant technical input. Many paywall software providers offer platforms and tools that enable relatively non-technical users to easily control content access rules and front-end elements, and to test and measure the efficacy of different offers, marketing tactics, product messages, pricing strategies and more. Depending on how they’re implemented, server-side approaches often require greater technical input and development resources to make such changes.

Less-technical SEO considerations

With a server-side paywall approach, search engine crawlers — like human visitors — cannot by default get access to paywalled content to “read” and evaluate it. As a result, publishers that intend to have their content crawled and indexed by Google typically adopt one of the following approaches, some of which require fairly complex technical implementation.

Use “lead-in” content to give both search engines and users access to a portion of a paywalled article or piece of content, such as the first 50-400 words, or the first 4 paragraphs.
Use “structured data” to ensure paywalled content is accessible to Google, but hidden from users and in a page’s underlying HTML.
In more advanced implementations, present paywalled content and structured data only to specific search engine crawlers — such as Googlebot — while hiding it from users and other bots.

Which approach is best between client-side and server-side?

Ultimately there are advantages and disadvantages to each, and deciding which is most suitable for a product depends on strategy, goals, content, business model, technical capabilities, resources, and other variables.

Broadly speaking, proponents of client-side paywalls will conclude:

Client-side approaches are more flexible and require less technological expertise to implement, which outweighs concerns about content security and piracy.
There’s no strong evidence that paywall circumvention results in significant revenue loss.
Relatively few visitors are technically capable of circumventing client-side paywalls, and those who are are unlikely to go to the effort.
Even when using server-side paywalls, publishers typically make paywalled content technically accessible to users via structured data anyway.
Even with a more “secure” server-side implementation, users can always share login credentials.
Visitors who go to the effort of circumventing a paywall are highly unlikely to pay, and should therefore be effectively ignored.
“Piracy” of content can ultimately lead to audience and revenue growth by exposing new users to its value.

On the other side of the coin, arguments against client-side paywalls include:

Visitors who go to the effort of circumventing a paywall are willing to do so because they see great value in the content. Giving them an opportunity to skirt paywalls inevitably results in lost sales and revenue, and there’s no strong evidence to prove that loss is insignificant.
Once visitors learn they can easily hack their way around a paywall, that knowledge will spread and the behavior will become more commonplace.
Client-side paywalls can result in longer load times and a janky pages, potentially having a negative impact on user experience, and on search rankings and traffic.
Password sharing is less prevalent and more cumbersome than circumventing a paywall.
When implemented carefully and correctly, client-side approaches strike the best balance between restricting user access to paywalled content and making it fully crawlable and indexable by Google and other search engines.

Key questions to consider when evaluating paywall methods

Owing to the various pros and cons for each method, deciding which paywall approach is best for a specific website or product is contingent on a range of variables. Publishers should ask themselves the following key questions to establish which approach is best for their specific needs, depending on the nature of their products, their resources and capabilities and their business priorities.

Is there a metered paywall? Metered paywalls that offer access to X pieces of content in a given period are inherently more “porous” than hard paywalls. Metered content is typically passed around more readily, and users can often wait for their meter limit to renew before accessing content they’re interested in or effectively “reset” their limits by using incognito browser windows or different devices. As a result, many publishers opt for a client-side paywall for metered content believing they provide greater flexibility and easier implementation.
How valuable are individual pieces of content? For some publishers, the value in their subscription products lies in unlimited access to many pieces of content rather than a select few. A news publisher might expect visitors to be interested in multiple pieces of content a day, assume that circumventing a paywall every time might prove less appealing to visitors than simply paying for access and opt for a client-side approach as a result. Meanwhile, for publishers that place greater value on single pieces of content — such as highly-valuable information, unique data or long-form reports — they might instead opt for a more secure server-side approach to help minimize access by non-paying visitors and also ensure valuable pieces of information aren’t readily displayed in search results.
What’s the nature of the audience? Some audiences are simply more likely to attempt to circumvent paywalls than others, based on a variety of factors. For example, tech-savvy readers are perhaps more likely to circumvent a paywall if they’re spending their own money compared with similar readers who can easily place a subscription on a corporate credit card. Meanwhile, relatively non-technical readers may not even be aware that bypassing a paywall is possible. As such, audience makeup and likely behavior is a key variable when weighing server-side or client-size approaches.
How important is search traffic? If a site relies primarily on search engines to direct traffic to it, a client-side approach may be preferred in order to ensure search engines can easily crawl their content. Alternatively, more sophisticated publishers might opt for server-side technology but couple it with an advanced approach to search engine crawling permissions. Elsewhere, publishers with high-value content that are less concerned with driving organic search traffic to their sites might instead opt for the added security that a server-side approach can provide, and worry little about whether Google can crawl and index its content effectively.
What development resources are available? Server-side paywalls often require more development and closer integration with content management systems and other technologies to work effectively. And as noted above, they typically require a more nuanced and technical implementation to ensure that content is visible to search engines without making it readily available to users. By contrast, client-side paywalls are often easier and quicker to implement, and can offer greater flexibility.

For more insights and detailed practical guidance on how publishers can run successful subscription products and businesses, see the Subscriptions Toolkit.