GET, POST & the Browser: How Modern Websites Communicate and What It Means for You

Author’s note:

Question: Explain how websites can do GET, POST, requests to other websites.

Context: Context:

i want to better understand how websites work, how the network tab on Google Chrome works, and what the basics of web communication are. i undstand what the curl command is, but that’s about it.

Executive Summary

Understanding how websites communicate via HTTP is fundamental to web development, security, and performance optimization. At the core of this communication are the GET and POST methods. GET is designed for retrieving data safely and is cacheable by default, making it ideal for reading resources like search results or product pages ^{1 2}. In contrast, POST is used to submit data that changes the server’s state, such as creating an order or uploading a file, and is generally not idempotent ^{1 2}.

Key strategic insights for developers include:

• Security Risks: HTML forms default to GET, which can accidentally expose sensitive data in URLs. Always use POST for sensitive actions ³.
• Cross-Origin Controls: The Same-Origin Policy restricts cross-site requests by default. Implementing Cross-Origin Resource Sharing (CORS) headers is essential for modern APIs to function securely across domains ^{4 5}.
• Tooling: The Chrome DevTools Network panel is the primary instrument for inspecting these requests, allowing developers to view headers, payloads, and timing data in real-time ⁶.
• Modern Standards: While XMLHttpRequest exists for legacy support, the Fetch API provides a more powerful, promise-based interface for making requests ^{7 8}.

Introduction – Why “GET vs POST” Still Matters in 2026

Every time you load a webpage, submit a form, or scroll through a social media feed, your browser is engaging in a rapid-fire conversation with servers around the world. This conversation happens primarily through HTTP (Hypertext Transfer Protocol). While there are several methods in the HTTP standard, GET and POST remain the workhorses of the web ¹.

For developers and curious users alike, distinguishing between these two is not just semantics—it dictates how data is cached, how security is handled, and how applications scale. A misunderstanding here can lead to security vulnerabilities like Cross-Site Request Forgery (CSRF) or performance bottlenecks where dynamic actions are aggressively cached ^{1 9}.

This guide breaks down the mechanics of these requests, how to inspect them using browser tools, and the security best practices required to keep them safe.

HTTP Methods Deep-Dive

The HTTP protocol defines a set of “methods” (often called verbs) that indicate the desired action to be performed for a given resource.

GET: The Safe Retriever

The GET method is used to request a representation of a specific resource ¹⁰.

• Data Location: Data is sent in the URL as query parameters (e.g., ?id=123&sort=asc) ¹.
• Safety: It is considered “safe,” meaning it should only retrieve data and not modify the server state ^{10 2}.
• Idempotency: It is “idempotent,” meaning making the same request multiple times produces the same result ^{1 2}.
• Cacheability: Responses are cacheable by default, allowing browsers and CDNs to store them for faster subsequent access ^{1 2}.

POST: The State Changer

The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server ¹⁰.

• Data Location: Data is sent in the request body, keeping it out of the URL ¹.
• Safety: It is “unsafe” because it modifies data (e.g., creating a user, processing a payment) ^{10 2}.
• Idempotency: It is not idempotent. Sending the same POST request twice (like refreshing a checkout page) may result in duplicate actions, such as double-charging a credit card ^{1 2}.
• Cacheability: POST responses are typically not cached unless explicit freshness information is provided ^{1 2}.

Method Property Comparison

• POST caching is possible but requires specific headers like Cache-Control and Content-Location ¹¹.

When to Use Which Method – Decision Matrix

Choosing the right method is critical for application stability and user experience.

HTML Form Mechanics

The humble HTML <form> element is the traditional way browsers issue HTTP requests.

Default Behavior

By default, if you do not specify a method, a form uses GET.

• Method Attribute: The method attribute controls the HTTP verb. It defaults to get if missing or invalid ³.
• Action Attribute: The action attribute specifies the URL where the data is sent ³.
• Enctype Attribute: The enctype attribute defines how the data is encoded. The default is application/x-www-form-urlencoded ³.

Security Implication

Because the default is GET, submitting a form without a method specified will append all form fields to the URL. If a form contains a password field, that password will appear in the address bar and browser history ^{1 3}.

Example of a Secure Form:

<!-- Always use POST for sensitive data -->
<form action="/login" method="post">
 <label for="username">Username:</label>
 <input type="text" id="username" name="username">
 <label for="password">Password:</label>
 <input type="password" id="password" name="password">
 <button type="submit">Log In</button>
</form>

Programmatic Requests: Fetch vs XMLHttpRequest

Modern web applications (Single Page Apps, etc.) often load data without refreshing the page. There are two primary APIs for this.

The Fetch API (Modern Standard)

The Fetch API provides a powerful and flexible interface for fetching resources. It uses Promises, making it easier to work with asynchronous operations compared to older callbacks ^{8 12}.

• Syntax: fetch() is a global method available in Window and Worker contexts ⁸.
• CORS: It integrates with Cross-Origin Resource Sharing (CORS) by default ¹².
• Error Handling: A fetch() promise resolves even if the server returns an error status (like 404 or 500); it only rejects on network failure ⁸.

Fetch Example:

fetch('https://api.example.com/data', {
 method: 'POST',
 headers: {
 'Content-Type': 'application/json'
 },
 body: JSON.stringify({ username: 'example' })
})
.then(response => response.json())
.then(data => console.log(data));

XMLHttpRequest (Legacy)

XMLHttpRequest (XHR) was the original way to retrieve data via JavaScript. While still supported, it is largely superseded by Fetch ⁷.

• Event-Based: It relies on event handlers like load and error rather than promises ⁷.
• Complexity: It often requires more boilerplate code to handle simple JSON requests compared to Fetch ⁷.

Same-Origin Policy & CORS Explained

Browsers enforce strict security rules to prevent malicious websites from reading data from other sites.

Same-Origin Policy (SOP)

The SOP restricts how a document or script loaded from one origin can interact with a resource from another origin. An origin is defined by the protocol (http/https), host (domain), and port ^{4 5}.

• Cross-origin writes (like form submissions) are typically allowed ⁵.
• Cross-origin reads (like reading the response of an API call) are typically disallowed by default ⁵.

Cross-Origin Resource Sharing (CORS)

CORS is a mechanism that uses HTTP headers to tell the browser to allow a web application running at one origin to access selected resources from a different origin ⁴.

• Preflight Requests: For “complex” requests (like those using methods other than GET/POST or custom headers), the browser first sends an OPTIONS request to check permissions ⁴.
• Key Headers: The server must respond with headers like Access-Control-Allow-Origin to permit the access ⁴.

Inspecting Requests with Chrome DevTools

The Network panel in Chrome DevTools is the ultimate source of truth for verifying what your browser is sending and receiving.

How to Use It

1. Open DevTools: Press Control+Shift+J (Windows/Linux) or Command+Option+J (Mac) ⁶.
2. Navigate to Network: Click the Network tab ⁶.
3. Reload/Interact: Perform the action (reload page, click button) to log activity ⁶.

Key Columns to Inspect

• Status: The HTTP response code (e.g., 200 OK, 404 Not Found) ⁶.
• Type: The type of resource (document, script, fetch, etc.) ⁶.
• Initiator: Shows what caused the request (e.g., a specific script line or HTML tag) ⁶.
• Waterfall: Visualizes the timing of the request, helping identify slow server responses or large downloads ⁶.

Filtering

You can filter requests to see only what you need. For example, clicking Fetch/XHR will show only API calls, hiding images and CSS ⁶.

Security Checklist

When implementing GET and POST requests, several security vectors must be managed.

1. Cross-Site Request Forgery (CSRF)

CSRF attacks trick a user’s browser into performing an unwanted action on a trusted site where the user is authenticated. This works because browsers automatically include cookies (like session IDs) with requests ⁹.

• Prevention: Use CSRF tokens (unique, unpredictable values) in state-changing requests (POST, PUT, DELETE) and validate them on the server ⁹.
• SameSite Cookies: Set the SameSite attribute on cookies to Strict or Lax to prevent them from being sent with cross-site requests ⁹.

2. Cross-Site Scripting (XSS)

XSS allows attackers to inject malicious scripts into webpages viewed by other users. If an attacker can execute script, they can bypass CSRF protections ^{9 13}.

• Prevention: Use Output Encoding to convert special characters into safe HTML entities. Implement a Content Security Policy (CSP) to restrict where scripts can load from ¹³.

3. HTTPS (TLS)

Transport Layer Security (TLS) ensures privacy and data integrity.

• Encryption: TLS encrypts the connection, preventing eavesdroppers from reading the data in transit (including POST bodies and GET URLs) ¹⁴.
• Authentication: It verifies that the server is who it claims to be ¹⁴.
• Requirement: Modern web features (like Service Workers and HTTP/2) often require HTTPS ¹⁴.

Caching POST Responses – When & How

While GET requests are cacheable by default, POST requests are generally not. However, the HTTP specification does allow caching POST responses under specific conditions.

• Explicit Freshness: The response must include explicit freshness information, such as a Cache-Control header with a max-age directive or an Expires header ¹¹.
• Content-Location: The response should include a Content-Location header that matches the POST’s target URI ¹¹.
• Invalidation: A cache must invalidate the stored response for a URL if it sees an unsafe method (like POST, PUT, DELETE) targeting that URL ¹¹.

Note: In practice, most caches and browsers primarily cache GET and HEAD requests ¹¹.

Bottom Line – Key Takeaways

1. Respect the Semantics: Use GET for reading data (safe, cacheable) and POST for modifying data (unsafe, non-idempotent) ^{1 2}.
2. Secure Your Forms: Always use method="post" for forms containing sensitive data to prevent it from leaking into the URL history ^{1 3}.
3. Modernize with Fetch: Prefer the Fetch API over XMLHttpRequest for cleaner, promise-based code that handles CORS and streaming natively ^{7 8}.
4. Inspect Everything: Use the Chrome DevTools Network panel to verify request headers, payloads, and status codes during development ⁶.
5. Layer Your Defenses: Implement HTTPS, CORS, and CSRF tokens to protect your application’s communication from common web attacks ^{9 14}.

References