What is an Ethereum RPC URL and how do you choose the right one?

When you build on Ethereum, the first thing your dApp needs is an RPC URL. It is the address your wallet, backend service, or indexer uses to send JSON-RPC requests to the blockchain. But not all Ethereum RPC URLs are equal. The endpoint you choose affects latency, reliability, data availability, and how much you pay as your traffic grows.

This article explains what an Ethereum RPC URL is, how to read one, and how to choose the right endpoint for your use case. You will also see concrete configuration examples and a comparison of public, managed, and dedicated options.

Ethereum RPC URL: what it is and how it works

An RPC (Remote Procedure Call) URL is the HTTP or WebSocket address that exposes the Ethereum JSON-RPC API. When your application calls eth_blockNumber or eth_getBalance, it sends a POST request to this URL with a JSON payload. The node behind the URL processes the request and returns a response.

A typical Ethereum RPC URL looks like this:

https://eth.api.onfinality.io/public

This URL points to a public endpoint hosted by OnFinality. It supports both HTTP and WebSocket, so you can use it for standard requests and real-time subscriptions.

Anatomy of an RPC URL

• Protocol: https:// or wss:// for WebSocket. Always use HTTPS/WSS in production to encrypt traffic.
• Host: The domain or IP address of the node provider.
• Path: Often includes the network name or an access key. For example, /public indicates a shared public endpoint.

HTTP vs WebSocket

• HTTP: Best for one-off requests like fetching block data or sending transactions. Most SDKs use HTTP by default.
• WebSocket: Enables push-based subscriptions like eth_subscribe. Use it for real-time updates, such as pending transactions or new blocks.

How to configure an Ethereum RPC URL in your stack

You will need an RPC URL in several places: your wallet, your dApp's frontend, and your backend services. Here are common configuration examples.

Wallet configuration (MetaMask)

In MetaMask, you can add a custom network with the following settings:

{
  "chainId": "0x1",
  "chainName": "Ethereum Mainnet",
  "rpcUrls": ["https://eth.api.onfinality.io/public"],
  "nativeCurrency": {
    "name": "Ether",
    "symbol": "ETH",
    "decimals": 18
  },
  "blockExplorerUrls": ["https://etherscan.io"]
}

ethers.js example

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://eth.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block:", blockNumber);
}

getBlockNumber();

viem example

import { createPublicClient, http } from 'viem';
import { mainnet } from 'viem/chains';

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://eth.api.onfinality.io/public'),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

WebSocket subscription example

const { WebSocket } = require("ws");
const ws = new WebSocket("wss://eth.api.onfinality.io/public");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "eth_subscribe",
    params: ["newHeads"]
  }));
});

ws.on("message", (data) => {
  console.log("New head:", JSON.parse(data.toString()));
});

Public, managed, or dedicated: which Ethereum RPC URL should you use?

Your choice of RPC URL depends on your workload, budget, and reliability requirements. Here is a quick comparison to help you decide.

Public RPC URLs

Public endpoints like https://eth.api.onfinality.io/public are free and easy to use. They are great for development and testing. However, they are shared across many users, so they can become slow or rate-limited under heavy load. They are not suitable for production applications that need consistent performance.

Managed shared RPC

Managed RPC services provide dedicated API endpoints with higher rate limits, better uptime, and technical support. They handle node infrastructure, so you do not need to run your own nodes. This is a good middle ground for most production dApps.

Dedicated nodes

A dedicated node gives you a private RPC URL that is not shared with other users. You get full control over the node's configuration, and you avoid the "noisy neighbor" problem. This is ideal for applications that make heavy use of eth_getLogs, archive data, or custom tracing.

How to evaluate an Ethereum RPC provider

When comparing RPC providers, look beyond the URL. Here are the key criteria to evaluate:

Reliability and uptime

Check the provider's historical uptime and whether they offer an SLA. A provider that has frequent outages will hurt your user experience. Look for providers that publish status pages and have redundant infrastructure.

Rate limits and fair use

Public endpoints often have strict rate limits. Managed services offer higher limits, but they may still cap your requests per second. Understand the limits and how they are enforced. If you need consistent throughput, a dedicated node may be necessary.

Data availability: archive and trace data

Many dApps need historical state or transaction traces. Archive nodes store the full history of the blockchain, which is essential for analytics, indexers, and some DeFi applications. Check if the provider offers archive data and whether it is included in your plan.

WebSocket support

If your dApp needs real-time updates, ensure the provider supports WebSocket connections. Some providers only offer HTTP, which limits your ability to subscribe to events.

Security and compliance

For enterprise use, consider the provider's security practices, such as encryption, access controls, and compliance certifications. A provider that offers dedicated infrastructure may give you more control over data privacy.

Production readiness checklist

Before you go live with an Ethereum RPC URL, run through this checklist:

• Use HTTPS/WSS: Never use plain HTTP in production.
• Set up fallback endpoints: Configure multiple RPC URLs in your client to handle failover.
• Monitor performance: Track latency, error rates, and request volume.
• Understand rate limits: Know your provider's limits and plan for spikes.
• Test archive data: If your app needs historical data, verify the provider supports it.
• Review the SLA: Ensure the provider offers a service-level agreement that meets your needs.

Common pitfalls and how to avoid them

Using a public endpoint in production

Public endpoints are convenient, but they are not designed for production traffic. You may hit rate limits or experience downtime. For any serious application, use a managed or dedicated RPC URL.

Ignoring WebSocket vs HTTP differences

If your app relies on real-time data, you need WebSocket. Using HTTP polling is inefficient and can miss events. Make sure your provider supports WebSocket and that you use the correct URL scheme (wss://).

Not planning for failover

A single RPC URL is a single point of failure. Use multiple providers or endpoints and implement automatic failover in your client. Libraries like ethers.js and viem support multiple providers.

Overlooking archive data needs

If your dApp queries historical state, you need an archive node. Many providers charge extra for archive access. Plan for this in your budget and choose a provider that offers archive data on the networks you need.

How to get started with an Ethereum RPC URL

If you are ready to move beyond public endpoints, OnFinality offers managed RPC services and dedicated nodes for Ethereum and many other networks. You can start with a free public endpoint to test, then upgrade to a production plan as your traffic grows.

• Explore supported networks to see all available chains.
• Check RPC pricing for transparent pricing on managed and dedicated options.
• Visit the Ethereum network page for specific endpoint details.

Key Takeaways

• An Ethereum RPC URL is the endpoint your dApp uses to interact with the blockchain.
• Public endpoints are fine for development, but production apps need managed or dedicated RPC URLs.
• Choose between HTTP and WebSocket based on your need for real-time data.
• Evaluate providers on reliability, rate limits, archive data, WebSocket support, and security.
• Always use HTTPS/WSS and set up failover for production.

Frequently Asked Questions

What is the official Ethereum RPC URL?

There is no single official Ethereum RPC URL. The Ethereum Foundation does not host a public RPC endpoint. Instead, you choose a provider like OnFinality that offers public, managed, or dedicated endpoints.

Can I use a free Ethereum RPC URL for production?

Free public endpoints are not recommended for production due to rate limits and potential downtime. For reliable service, consider a managed RPC plan or a dedicated node.

How do I find my Ethereum RPC URL?

If you use a provider like OnFinality, you will receive an RPC URL in your dashboard. For public endpoints, you can use the URL provided on the network page, such as https://eth.api.onfinality.io/public.

What is the difference between HTTP and WebSocket RPC URLs?

HTTP is for standard request-response calls, while WebSocket allows for real-time subscriptions. Use WebSocket for features like pending transaction notifications or new block alerts.

Do I need an archive node for Ethereum?

If your application needs historical state or event logs beyond a certain age, you need an archive node. Many providers offer archive access as an add-on.

How can I test my Ethereum RPC URL?

You can use curl to send a simple JSON-RPC request:

curl -X POST https://eth.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

This should return the latest block number in hexadecimal format.