How to Disable WordPress REST API

You don’t always need WordPress REST API. In fact, sometimes you’re better off without it.

This post is for people who want to shut it down fast. Maybe you’re worried about someone poking around your site’s data. Maybe your server’s feeling the load. Maybe you just want one less thing “exposed.” Whatever your reason, I’ll show you how to disable the REST API cleanly and completely.

I’m not going to over-complicate it. You’ll get two plugin methods and two code snippet methods. One blocks the whole thing like it never existed. The other leaves it technically “on” but blocks every call with a clear message. You’ll know exactly when to use each one and why.

Key Takeaways

  • Install a plugin like “Disable WP REST API” to turn off REST API instantly without needing to write any code.
  • Use a code snippet to completely block REST routes, returning 404s and improving performance by not registering endpoints at all.
  • Use a different code snippet if you want to keep endpoints visible but return a clear JSON error for every request.

What is the REST API?

The answer will really depend on how technical you want to get about this.

Let me give you two versions of the answer actually. First, what WordPress REST API is in a nutshell:

The WordPress REST API turns your WordPress site into a JSON-based web service.

Any client (browser, mobile app, another server) can use standard HTTP requests to read or manipulate posts, pages, comments, users, and custom data. All that without having to load a PHP-rendered page.

It’s what powers modern JavaScript-heavy interfaces (like the crowd favorite block editor), headless WordPress setups, and third-party integrations.

If you’re not using it, or if you worry about exposing data, you can disable or lock it down.

A more technical take on the REST API:

The WordPress REST API is a system of HTTP endpoints that lets you interact with your WordPress data (think posts, pages, etc.) from outside the native dashboard.

In other words, REST “exposes” WordPress content and functionality as JSON-formatted data over otherwise standard HTTP requests.

REST stands for Representational State Transfer. I know, this doesn’t tell a lot, but in practical terms it means:

  • You use standard HTTP methods like GET, POST, PUT/PATCH, DELETE to interact with data on a WordPress site.
  • The server (meaning WordPress) returns data in a format that’s easy to process – typically JSON.
  • Each “thing” (a post, a user, a comment, etc.) has its own unique URL (aka. “endpoint”).

So REST API is simply an API that allows you to follow the above and use it to communicate with a WordPress site through special URLs, like this one:

https://YOURSITE.com/wp-json/wp/v2

You’ll find a number of endpoints under a URL like that:

  • GET /wp-json/wp/v2/posts
  • GET /wp-json/wp/v2/posts/{id}
  • POST /wp-json/wp/v2/posts
  • PUT/PATCH /wp-json/wp/v2/posts/{id}
  • DELETE /wp-json/wp/v2/posts/{id}

Let’s not get into the specifics on how to interact with them, but just know that REST API has a number of possible applications, such as:

  • Headless sites or interfaces – using WordPress data in a different wrapper.
  • Mobile apps – similar.
  • Third-party integrations with tools like Zapier, IFTTT, and others.
  • Enhanced UI or core features. So the block editor is essentially a React app that lives inside wp-admin, speaking to WordPress via REST endpoints behind the scenes.

Why you might want to disable the REST API in WordPress

Okay, so if REST API is so awesome then why would you want to disable it? There are a couple of reasons you might want to do it:

  • Security/privacy concerns. By default, even unauthenticated users can fetch “public” data (like a list of published posts or the list of users/authors). This might not be the best situation if you’re running a site that’s not meant to be 100% public.
  • Performance. Every registered REST route adds a bit of overhead to your site’s initialization. On very high-traffic sites (or with many custom endpoints), this can add up.
  • Fewer attack points. Every endpoint is potentially one more place for bots or attackers to hit.

Okay, so with all that said, how do you actually disable REST API in WordPress?

How to disable WordPress REST API (best methods)

As with most things in WordPress, there are two paths you can take:

  1. The plugin approach
  2. The manual approach

Though the manual approach isn’t actually much harder, and can be better in some scenarios.

Method 1: Using a plugin 🔌

There are more than a handful of plugins that let you disable REST API, and they will all do the job well. I’m saying this just to make clear that there isn’t only “one correct solution” here.

My two favorite ones are:

👉 (a) A plugin simply called “Disable WP REST API” – the name makes it clear, doesn’t it?

It’s also super-easy to use, since you only have to install and activate it…and that’s it. No settings, no dashboard panel.

What happens is that this plugin completely disables REST API unless the user is logged into WordPress. Therefore:

  • For logged-in users, REST API works normally.
  • For not-logged-in users, REST API is disabled. Perfect!

👉 (b) A plugin called “Admin and Site Enhancements (ASE).”

This one’s a bit more feature rich – it does a lot more than just letting you disable REST API. I’m listing it since you might decide this is going to be a better solution in your case if you’re going to end up using more of the plugin’s features.

When it comes to disabling REST API, there’s a simple toggle in the plugin’s settings for that:

rest toggle

So just tick the toggle and then click on Save Changes. Done!

Method 2: Using a code snippet 💾

Okay, so now the more manual path.

In all honesty, disabling REST API is simple enough that you don’t really need a specialized plugin just for that. You can use a code snippet and get the same effect. Plus, you even get more control of the outcome.

I’m going to show you two different code snippets you can use to disable REST API under different conditions – use the one that matches your situation better…or use the first one if you’re not sure. 🤣

(a) Prevent endpoint registration altogether.

Here’s the snippet:

add_filter( 'rest_enabled', '__return_false' );
add_filter( 'rest_jsonp_enabled', '__return_false' );

Here’s what’s going on: As soon as WordPress initializes its REST mechanisms, the rest_enabled filter fires. But since we return false here, we’re telling it to never register any REST routes. Then, rest_jsonp_enabled returning false stops JSONP wrappers from even being created.

Therefore, if any incoming request is made, every /wp-json/ URL immediately returns a 404 (because there are literally no routes registered).

There’s no authentication check, no JSON-error message. It’s just WordPress acting as if REST API simply didn’t exist.

Use this snippet if you want REST to be “invisible.” 👍

Pros:

  • Great for performance. WordPress never registers any of the REST routes in the first place.
  • Clean 404 behavior. Meaning that nothing in the output reveals that REST API is disabled.

Cons:

  • If another plugin (or theme) tries to register custom REST routes later, they’ll also be blocked.

(b) Deny every incoming request.

Here’s the snippet:

add_filter( 'rest_authentication_errors', 'disable_rest_api' );

function disable_rest_api( $access ) {
    return new WP_Error(
        'rest_disabled',
        __( 'The WordPress REST API has been disabled.' ),
        array( 'status' => rest_authorization_required_code() )
    );
}

Here’s what’s going on: The rest_authentication_errors filter runs right when WordPress is about to check whether the current REST request is allowed. However, we’re forcing this to always return a WP_Error, which basically means that we’re denying every incoming request (whether authenticated or not).

More specifically, any call to /wp-json/ returns a JSON error object like this:

{ "code": "rest_disabled", "message": "The WordPress REST API has been disabled.", "data": { "status": 401 } }

Use this snippet if you’d rather give API clients a clear “disabled” message. 👍

Pros:

  • All routes are still “registered” behind the scenes. It’s just that every request gets a WP_Error. That means if some plugin or theme tries to check for the existence of your custom route, the route is still registered (it just won’t ever return useful data).
  • You get an explicit JSON error response instead of a 404.

Cons:

  • Slightly less performant. WordPress still registers every core REST route (and any third-party route), then immediately blocks it on authentication.
  • Plugins/themes that do something at route-registration time may still run, even though the route will be forbidden later.

So, which snippet do you prefer?

“Wait, where do I include this code snippet?”

My favorite approach is to use the Code Snippets plugin. Install, activate, and then go to Snippets → Add New from the WordPress dashboard. Copy and paste your snippet there. Make sure to select Run snippet everywhere and click on Save Changes and Activate.

add new snippet

Conclusion

While REST API can be useful in certain scenarios and for some WordPress sites, it’s clearly not for everyone. This is why disabling it makes sense in some cases.

I’ve shown you two ways to get rid of it…actually, I showed you four: two plugins and two different snippets. You have more than enough solutions to choose from! 😃

Do you have any questions about the WordPress REST API or how to disable it? Let us know in the comments section below!

Yay! 🎉 You made it to the end of the article!

0 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments

Or start the conversation in our Facebook group for WordPress professionals. Find answers, share tips, and get help from other WordPress experts. Join now (it’s free)!