Forem: reynaldi

How to Set the Host Header in Fetch (JavaScript)

reynaldi — Fri, 27 Feb 2026 04:24:55 +0000

The Host header is a forbidden header name in the browser, which means JavaScript cannot set it using fetch() or XMLHttpRequest. If you need to control the Host header for API integrations or web scraping, the solution is to route the request through a server-side proxy that can set the header for you.

Quick Solution

Use Corsfix to set the Host header from your frontend code. Pass the header you want inside x-corsfix-headers, and Corsfix will apply it server-side before forwarding your request.

fetch("https://proxy.corsfix.com/?https://api.example.com/data", {
  headers: {
    "x-corsfix-headers": JSON.stringify({
      Host: "api.example.com",
    }),
  },
})
  .then((response) => response.json())
  .then((data) => console.log(data));

Corsfix receives your request, sets the Host header to the value you specified, and forwards it to the target URL. The response is then returned to your browser with the proper CORS headers.

For local development, this works instantly without registration. For live websites, set up your domain (takes 30 seconds).

Why Browsers Block the Host Header

The Host header is part of the browser's forbidden header names list. This is a set of headers that the browser manages automatically and doesn't allow JavaScript to modify. The Host header tells the server which domain the request is intended for, and browsers set it based on the URL you're requesting.

This is purely a browser-level restriction. In server-side environments like Node.js, you have full control over all headers including Host:

// Node.js — this works fine
const response = await fetch("https://api.example.com/data", {
  headers: {
    Host: "custom-host.example.com",
  },
});

// Browser — this is silently ignored
fetch("https://api.example.com/data", {
  headers: {
    Host: "custom-host.example.com", // Browser ignores this
  },
});

In the browser, the Host header you set is silently ignored and the browser uses the hostname from the URL instead. That's where a proxy comes in.

How a Proxy Solves the Problem

Since browsers won't let you set the Host header directly, the workaround is to let a proxy do it for you.

Your browser sends a request to Corsfix with the target URL and the headers you want to override inside x-corsfix-headers.
Corsfix reads the override instructions, sets the actual Host header on the outbound request, and forwards it to the target API.
The target API receives the request with the Host header value you specified.

When Do You Need to Set the Host Header?

There are a few real-world scenarios where controlling the Host header matters:

Virtual hosting — the target server hosts multiple domains on the same IP address and uses the Host header to route requests to the correct site.
API gateways — some API gateways validate the Host header and reject requests where it doesn't match the expected value.
Web scraping — certain websites check the Host header as part of their bot-detection logic and block requests with unexpected values.
SNI and TLS routing — servers behind load balancers may use the Host header to determine which TLS certificate to serve.

Best Practices

Only Override What You Need

Don't override the Host header on every request. Only use it when the target API specifically requires a particular Host value. In most cases, the default behavior (using the hostname from the URL) is correct.

Handle Errors Gracefully

When the Host header doesn't match what the server expects, you may get unexpected errors:

const response = await fetch(
  "https://proxy.corsfix.com/?https://api.example.com/data",
  {
    headers: {
      "x-corsfix-headers": JSON.stringify({
        Host: "custom-host.example.com",
      }),
    },
  }
);

if (!response.ok) {
  // Common errors when Host is misconfigured:
  // 403 Forbidden — server rejected the Host value
  // 421 Misdirected Request — Host doesn't match the server
  // 502 Bad Gateway — upstream server couldn't route the request
  console.error(`Request failed: ${response.status}`);
}

Conclusion

Use a server-side proxy like Corsfix to set the Host header in JavaScript fetch. Since browsers restrict the Host header as a forbidden header name, a proxy is the simplest way to override it without setting up your own backend.

Corsfix handles the Host header override (along with other forbidden headers) server-side, so you can focus on building your app instead of managing proxy infrastructure. It's free to get started, and you only need to upgrade when you go to production.

Building a File Sharing App with Puter.js

reynaldi — Tue, 24 Feb 2026 08:45:16 +0000

In this tutorial, we'll build a file sharing app that lets you upload any file and instantly get a shareable public URL using Puter.js.

Demo: https://file-sharing-example.puter.site/

Key Features

Our file sharing app provides a simple drag-and-drop interface for sharing files:

Drag & drop upload: Select files by dragging them onto the page or clicking to browse
Cloud storage: Files are stored in Puter's cloud file system
Public URLs: Each uploaded file gets a public URL via Puter Hosting
Persistent subdomain: The app remembers your subdomain across sessions using Puter KV

Getting Started

This app is a single index.html file with no build step. Add Puter.js via CDN:

<script src="https://js.puter.com/v2/"></script>

Puter.js is a JavaScript library that provides features like AI, cloud file storage, database, hosting, and authentication, all running client-side with a User-Pays Model.

Building the App

The app includes a drag-and-drop UI, file previews, and progress indicators. This tutorial focuses on the Puter.js APIs that power it. You can find the full source code here.

When the user selects a file and clicks upload, three things happen using Puter.js:

Create a hosted subdomain to serve files publicly
Upload the file to Puter's cloud file system
Generate a public link from the subdomain and file name

Creating a Hosted Subdomain

Before uploading, we need a place to serve the files. Puter Hosting lets you create a subdomain under *.puter.site that maps to your cloud file system. We create one on first use and save it with puter.kv so it persists across sessions:

// Check if we already have a subdomain from a previous session
let subdomain = await puter.kv.get("site_subdomain");

if (!subdomain) {
  // First time: generate a unique subdomain and create the site
  subdomain = "file-" + crypto.randomUUID().split("-")[0];
  await puter.hosting.create(subdomain, ".");
  await puter.kv.set("site_subdomain", subdomain);
}

puter.hosting.create(subdomain, directory) links the subdomain to a directory in Puter's file system. Here we point it at "." (the app root), so any file we write to will be accessible at https://<subdomain>.puter.site/<filename>.

puter.kv acts as a simple key-value database. By saving the subdomain here, subsequent visits skip the creation step and reuse the same subdomain.

Uploading the File

With the subdomain ready, we write the file to Puter's cloud file system. To avoid name collisions, we prefix the file name with a short UUID:

// Generate a unique file name to avoid collisions
const extension = selectedFile.name.includes(".")
  ? "." + selectedFile.name.split(".").pop()
  : "";
const uniqueName = crypto.randomUUID().split("-")[0] + extension;

// Write the file to Puter's cloud file system
await puter.fs.write(uniqueName, selectedFile);

puter.fs.write(path, content) writes any File, Blob, or string to the user's cloud storage. Since our hosted site points at the root directory, this file is now publicly accessible.

Generating the Public Link

The public URL is simply the subdomain plus the file name:

const publicUrl = `https://${subdomain}.puter.site/${encodeURIComponent(uniqueName)}`;

We use encodeURIComponent on the file name to handle any special characters in the extension or UUID. The user can now copy this URL and share it with anyone.

Conclusion

You've now built a file sharing app with Puter.js by combining:

Puter File System: Storing uploaded files in the cloud with puter.fs.write
Puter Hosting: Creating a public *.puter.site subdomain to serve files with puter.hosting.create
Puter Key-Value Store: Persisting the subdomain across sessions with puter.kv

The best part? With Puter's User-Pays Model, you can deploy this app for free. Users authenticate with their own Puter account, so they cover their own usage, making your app free to run and scale.

Demo: https://file-sharing-example.puter.site/

Source Code: https://github.com/Puter-Apps/file-sharing

Get started with Puter.js and access features like AI, cloud storage, key-value stores, hosting, and more.

Building an AI-Powered RAG Application with Puter.js

reynaldi — Fri, 06 Feb 2026 13:24:14 +0000

In this tutorial, we'll build a RAG (Retrieval-Augmented Generation) application that lets you chat with any website using Puter.js.

Demo: https://stampy.puter.site/

Key Features

Our RAG application allows you to chat with any website, with answers grounded in the actual website content:

Add any website: Enter a sitemap URL to index an entire site
Retrieval: Full-text search across all indexed pages using MiniSearch
Generation: AI-powered chat with function calling via Puter AI

What is RAG? RAG combines information retrieval with AI text generation. Instead of relying solely on an AI model's training data, RAG first searches through relevant documents, then uses that context to generate accurate, grounded responses. This means the AI can answer questions about specific content it was never trained on.

Getting Started

Set up your project with any JavaScript framework you prefer (React, Vue, Svelte, or even vanilla JS), then add Puter.js:

npm install @heyputer/puter.js

or, via CDN:

<script src="https://js.puter.com/v2/"></script>

Puter.js is a JavaScript library that provides features like AI, cloud file storage, database, networking, and authentication, all running client-side with a User-Pays Model.

You can find the full Puter.js documentation here.

Building the App

Our RAG app works in three stages:

Crawl & Store: Fetch all pages from a website's sitemap, extract the text content, and store it in Puter's cloud file system. Site metadata is persisted in Puter's key-value database
Index for Search: Build a search index from the stored documents so we can quickly find relevant content
AI Chat with Function Calling: Let the AI decide when to search the documents and use the results to generate grounded answers

Crawling the Website

We start by fetching the website's sitemap, an XML file that lists all pages on a site. This gives us a list of URLs to crawl:

// Fetch the sitemap using Puter's networking
const response = await puter.net.fetch(sitemapUrl);
const sitemapContent = await response.text();

// Parse URLs from the sitemap XML
function parseSitemapUrls(xmlContent) {
  const parser = new DOMParser();
  const xmlDoc = parser.parseFromString(xmlContent, "text/xml");
  const locElements = xmlDoc.querySelectorAll("urlset url loc");
  return Array.from(locElements).map((loc) => loc.textContent || "");
}

const urls = parseSitemapUrls(sitemapContent);

Once we have all the URLs, we fetch each page and extract the text content. To save tokens and help the AI understand the page content, we strip away all the markup and keep just the meaningful text:

async function fetchHTMLContent(url) {
  const response = await puter.net.fetch(url);
  return await response.text();
}

function parseHTMLContent(html, url) {
  const parser = new DOMParser();
  const doc = parser.parseFromString(html, "text/html");
  const title = doc.querySelector("title")?.textContent?.trim() || "";
  const text = doc.querySelector("body")?.textContent?.trim() || "";

  const urlObj = new URL(url);
  return {
    id: `${urlObj.hostname}${urlObj.pathname}#content.txt`,
    title,
    text,
  };
}

// Crawl all pages and build the documents array
const documents = [];
for (const url of urls) {
  const html = await fetchHTMLContent(url);
  if (html) {
    documents.push(parseHTMLContent(html, url));
  }
}

Finally, we store each document in Puter's cloud file system. This gives us persistent storage without needing to set up a database or backend server. The documents are saved to the user's Puter account and will be available across sessions:

for (const doc of documents) {
  await puter.fs.write(doc.id, doc.text, {
    createMissingParents: true,
  });
}

Managing Sites with Puter Key-Value Store

While Puter's file system stores the actual document content, we need a way to keep track of which sites have been indexed. Puter's key-value store (puter.kv) works as a database for this: we store a list of site entries, each containing the site name, hostname, sitemap URL, and the path to its search index.

Loading the list of indexed sites is straightforward:

const websites = await puter.kv.get("websites");

When a user adds a new site (after crawling and indexing), we save the site entry with its metadata:

const hostname = new URL(sitemapUrl).hostname;

const newSite = {
  id: crypto.randomUUID(),
  name: name,
  hostname: hostname,
  sitemap_url: sitemapUrl,
  index_path: `${hostname}/index.json`,
};

const updatedSites = [...sites, newSite];
await puter.kv.set("websites", updatedSites);

Deleting a site removes it from both the key-value store and the file system:

// Remove the site's files from Puter FS
await puter.fs.delete(site.hostname);

// Update the site list in Puter KV
const updatedSites = sites.filter((s) => s.id !== site.id);
await puter.kv.set("websites", updatedSites);

This separation keeps things clean: puter.fs handles the heavy content storage, while puter.kv acts as a database for site metadata. Both persist to the user's Puter account, so everything is available across sessions without any backend setup.

Adding Search for Website Content

At this point, we have document content in Puter FS and site metadata in Puter KV. But to answer user questions, we still need a way to quickly find the right documents. This is the "Retrieval" in RAG: before the AI generates an answer, we first retrieve the most relevant documents to give it context.

We use MiniSearch, a lightweight full-text search library that runs entirely in the browser. A search index works like a book's index: instead of scanning every page to find a word, you look it up and jump straight to the relevant pages. This makes searching thousands of documents nearly instant:

// Create and populate the search index from the crawled documents
const miniSearch = new MiniSearch({
  fields: ["title", "text"],  // Fields to index
});
miniSearch.addAll(documents);

// Serialize and store the index in Puter FS
const hostname = new URL(sitemapUrl).hostname;
const searchIndexPath = `${hostname}/index.json`;
const searchIndex = JSON.stringify(miniSearch);
await puter.fs.write(searchIndexPath, searchIndex, {
  createMissingParents: true,
});

When a user selects a site and asks a question, we load its saved index and search for relevant documents. MiniSearch returns results ranked by relevance, so we take the top matches to use as context for the AI:

// Load the saved index from Puter FS using the site's index path
const indexBlob = await puter.fs.read(site.index_path);
const indexData = await indexBlob.text();
const miniSearch = MiniSearch.loadJSON(indexData, {
  fields: ["title", "text"],
});

// Search and get top results
const searchResults = miniSearch.search(query);
const topResults = searchResults.slice(0, 5);

Adding AI Chat with Function Calling

This is where everything comes together. We use Puter AI with function calling, a feature that lets the AI decide when to search the documents rather than us hardcoding when to search.

Function calling works by giving the AI a list of "tools" it can use. We describe what each tool does, and the AI autonomously decides when to call them based on the conversation. For our RAG app, we define a search tool that the AI will call whenever it needs information from the indexed website:

const tools = [
  {
    type: "function",
    function: {
      name: "search_documents",
      description: "Search through website documents to find relevant information",
      parameters: {
        type: "object",
        properties: {
          query: {
            type: "string",
            description: "The search query to find relevant documents",
          },
        },
        required: ["query"],
      },
    },
  },
];

The chat flow works in two steps. First, we send the user's question to the AI along with our tool definitions. The AI analyzes the question and decides whether it needs to search for information. If it does, it returns a "tool call" instead of a direct answer. We then execute that search, feed the results back to the AI, and let it generate a final response grounded in the actual document content:

const systemPrompt = {
  role: "system",
  content: "Answer in the context of the document. Search documents before clarifying with users.",
};

// Build conversation from system prompt and user messages
const conversationMessages = [systemPrompt, ...userMessages];

// First call: AI decides whether to search
const response = await puter.ai.chat(conversationMessages, false, {
  model: "openrouter:google/gemini-2.5-flash-lite",
  tools: tools,
  stream: false,
});

// If AI called the search tool, execute it
if (response.message.tool_calls?.length > 0) {
  const toolCall = response.message.tool_calls[0];
  const args = JSON.parse(toolCall.function.arguments);

  // Execute search and fetch document contents
  const searchResults = miniSearch.search(args.query).slice(0, 5);
  const documentContents = [];

  for (const result of searchResults) {
    const blob = await puter.fs.read(result.id);
    documentContents.push(await blob.text());
  }

  // Add tool result to conversation
  conversationMessages.push({
    role: "tool",
    tool_call_id: toolCall.id,
    content: documentContents.join("\n\n"),
  });

  // Second call: Generate final response with context
  const finalResponse = await puter.ai.chat(conversationMessages, false, {
    model: "openrouter:google/gemini-2.5-flash-lite",
    stream: true,  // Stream for better UX
  });
}

Conclusion

You've now built an AI-powered RAG application with Puter.js by incorporating:

Puter Networking: Fetching website content without CORS issues
Puter File System: Storing document content and search indexes in the cloud
Puter Key-Value Store: Managing site metadata as a database
MiniSearch: Full-text search for document retrieval
Puter AI: Chat with function calling for intelligent document search

The best part? With Puter's User-Pays Model, you can deploy this app for free. Users authenticate with their own Puter account, so they cover their own usage, making your app free to run and scale.

Demo: https://stampy.puter.site/

Source Code: https://github.com/Puter-Apps/stampy

Get started with Puter.js and access features like AI, cloud storage, key-value stores, and more.

Why Most APIs Don't Enable CORS?

reynaldi — Mon, 13 Oct 2025 10:50:00 +0000

You might be wondering why some APIs don't enable CORS, and what exactly they're trying to protect. After all, what's the problem in calling it from a browser?

In this article, we'll explore the reasons why APIs don't enable CORS, debunk some common misconceptions, and look at how you can ethically work with these APIs when you need client-side access.

Why Most APIs Don't Enable CORS

Server-to-Server Communication by Design

Many APIs are specifically designed for server-to-server communication. Usage in the browser wasn't part of the original plan, and the API makers want to maintain. By not enabling CORS, they can assert control over how their API is consumed, ensuring it's only called from server-side.

Preventing API Token Leakage

When an API requires authentication tokens, having those tokens on the client side creates a security risk. Developers might mistakenly include tokens directly in frontend code, where they become visible to anyone who views the source or inspects network requests. By disabling CORS, API providers push developers to use server-side implementations.

Rate Limiting and Access Control

Having an API only accessible without CORS means that typically only servers can call it, compared to allowing it to be called freely on any website. This makes rate limiting much more manageable for several reasons:

Easier to identify clients: Server-side requests are easier to track and attribute to specific users or organizations
Reduced volume: Without client-side access, there's inherently less request volume since each user isn't making direct API calls
Better enforcement: Rate limits can be more effectively enforced when requests come from a controlled number of server origins

What It's NOT Protecting

CORS Is Not A Protection For Session Hijacking

While some sources claim that disabling CORS protects against credential theft or session hijacking, this is misleading at best. CORS is not a security mechanism, it's an access control mechanism, as the name itself suggests: Access-Control-Allow-Origin.

If you want to protect against credential theft and CSRF attacks, you need to use different mechanisms entirely, such as:

Cookie attributes like HttpOnly, Secure, and SameSite=Lax or SameSite=Strict
CSRF tokens
Proper authentication headers instead of cookie-based auth for APIs

These mechanisms prevent credentials from being included in unauthorized cross-origin requests. CORS simply controls whether a browser allows your JavaScript to read a response.

Where Does a CORS Proxy Fit Here?

A CORS proxy like Corsfix allows you to call and fetch APIs directly from the client side while still being respectful of the API provider's intentions. Here's how:

For Server-to-Server Communication Requirements

Corsfix provides an easy method for developers to call these APIs while still conforming to the requirement of server-side execution, your requests go through a server (the proxy) rather than directly from the browser.

// GET request
fetch("https://proxy.corsfix.com/?https://api.example.com/users")
  .then((response) => response.json())
  .then((data) => console.log(data));

For Preventing API Token Exposure

Corsfix has first-class support for secrets, allowing you to securely store tokens and use them in your requests without exposing them in client-side code:

// Instead of exposing your token in the frontend:
// ❌ Don't do this
fetch("https://api.example.com/data", {
  headers: { Authorization: "Bearer sk-123..." },
});

// ✅ Use Corsfix with secrets variable
fetch("https://proxy.corsfix.com/?<url>", {
  headers: { Authorization: "Bearer {{SECRET_TOKEN}}" },
});

This ensures you never expose secrets while still having access to a wide range of APIs from your frontend application.

For Rate Limiting Concerns

The target API can still limit throughput for requests coming through the proxy, which is important for maintaining their service quality. Additionally, Corsfix provides caching features that:

Reduce load on the target server by serving cached responses when appropriate
Provide better performance to end users since cached requests return instantly
Help you stay within rate limits by reducing redundant API calls

fetch("https://proxy.corsfix.com/?<url>", {
  headers: {
    "x-corsfix-cache": "true",
  },
});

Conclusion

APIs don't enable CORS for reasons such as: to enforce server-to-server communication patterns, prevent API token leakage, and maintain rate limiting.

It's important to understand that CORS isn't a security protection mechanism, it's an access control mechanism, as clearly indicated by its name.

When you need to call these APIs from client-side code, you can use a CORS proxy like Corsfix.

Building an HTML-to-Image Website Screenshot Tool

reynaldi — Wed, 01 Oct 2025 10:29:12 +0000

Most website screenshot tools require backend infrastructure and setting up browser instances, but you can build one entirely in the frontend using modern JavaScript libraries and a CORS proxy.

In this article you will learn how to build a website screenshot tool from scratch directly in the frontend.

Website Screenshot Tool

Live demo: https://corsfix.com/tools/website-screenshot

How Screenshot Tools Typically Work

Most screenshot tools you see online use backend systems like Puppeteer, where there's an actual server running a headless browser instance to capture screenshots.

This approach works well because it shows accurate screenshots as if someone opened the page in their browser. The rendering engine handles JavaScript, CSS, and fonts exactly as a real browser would.

But there's an overhead, as you need server infrastructure, and you're running entire browser instances just to take screenshots, as well as you have to manage scaling and resource allocation.

Alternative: In-Browser HTML to Image

Website screenshots are fundamentally about converting a page's visual elements, which are its HTML structure and CSS styling, into an image.

You'd think there should be a way to render and convert HTML and CSS directly into an image without spinning up a browser instance, and you'd be right.

snapDOM is a JavaScript library that converts HTML to images directly in the browser. It's more up-to-date and faster than its predecessors like html2canvas.

snapDOM

Getting the website HTML

We have the first part figured out, which is snapDOM for HTML-to-image conversion. Next, thing to figure out is how to get the actual HTML to input in our library.

We need the actual HTML content from the target website. But directly fetching HTML from another domain results in CORS errors, where browsers block cross-origin requests.

This is where Corsfix comes in. It's a CORS proxy that lets you fetch HTML from any domain without CORS errors, making it possible to get the content you need directly from the browser.

Corsfix CORS proxy

Putting It All Together

The implementation flow:

Fetch the HTML using Corsfix to bypass CORS restrictions
Render the HTML using iframe as container
Let Snapdom process the HTML, render it with styles and fonts, and produce the image

// Simplified example
const url = "https://example.com";
const proxyUrl = `https://proxy.corsfix.com/?url=${encodeURIComponent(url)}`;

// Fetch HTML through proxy
const response = await fetch(proxyUrl);
const html = await response.text();

// Render in iframe
const iframe = document.createElement("iframe");
iframe.srcdoc = html;
document.body.appendChild(iframe);

// Convert to image with Snapdom
const screenshot = await snapdom.toImg(iframe.contentDocument.body);

Find the complete demo: https://corsfix.com/tools/website-screenshot

Conclusion

You can build a website screenshot tool using Corsfix for fetching HTML content and snapDOM for HTML-to-image conversion. This eliminates the need for backend servers and browser instances.

Solve CORS errors instantly with Corsfix, it's free to start and you only upgrade when moving to production.

How Much Bandwidth Do You Need for an API in 2025?

reynaldi — Sun, 10 Aug 2025 03:50:32 +0000

When talking about bandwidth or data transfer in the context of the web, most people think of bandwidth used by the actual webpages that you host. Thanks to a report by HTTP Archive, we know that webpages in 2025 weigh around 2.5 MB.

Page Weight (source: HTTP Archive)

This page weight includes everything that gets downloaded to render a page, like HTML, CSS, JS, fonts, images, and other assets.

However, this does not tell the story about bandwidth used for APIs.

Websites Are Heavy

It's tempting to assume that HTML, CSS, and JS are tiny since they are just text. However, HTML itself is bloated since you need to use markup tags, not including the attributes and more inline data.

Add to that:

CSS frameworks that load hundreds of KB
JavaScript bundles
Images, assets, fonts
Tracking scripts, analytics, etc.

So it's not a surprise that when talking about websites, they are in the MB range.

APIs Are a Different Story

There's no equivalent report for APIs similar to HTTP Archive for webpages. However, we can make some educated estimates.

APIs typically send structured data, mostly in JSON format, without extra markup, styles, or images. To put this into perspective, here is a 128 KB dummy JSON data.

128 KB JSON

It contains over 700+ objects, each with multiple fields. In most scenarios, an API response in this size range (100KB) is already considered large.

Estimate: APIs Are 20x Lighter Than Webpages

If we compare:

Type	Size	Content
Webpage	~2.5MB	HTML, CSS, JS, images, assets
API	~100 KB	Mostly text JSON data

That's a 20x difference. If a webpage consumes that amount of bandwidth, an API request would likely be 5% of that.

What This Means for Bandwidth Planning

For a website with heavy assets, total data transfer can easily reach hundreds of gigabytes or even terabytes per month at scale. This is why you see website hosting providers offer a lot of bandwidth compared to API services.

APIs, however, are much lighter. So your data transfer costs and bandwidth needs for APIs are often much lower than for a full website, even with the same number of requests.

Conclusion

APIs are significantly lighter compared to webpages. They can be up to 20x lighter than websites, even with the same number of requests. When planning for bandwidth needs or data transfer usage with APIs, you can expect to use much less data compared to your web hosting requirements.

Building a Real-Time Forex Rate Conversion App with Finage API

reynaldi — Wed, 30 Jul 2025 12:48:24 +0000

In the world of international finance and travel, having access to real-time currency exchange rates is essential. The Finage API provides reliable and up-to-date forex data that you can integrate into your applications.

In this article, you'll learn what it takes to build a modern, static-first, responsive forex conversion application. The app will feature real-time currency conversion, and a clean user interface.

Live Demo | Source Code

What's in our Forex Conversion App?
Setting Up The Project
Building the Application
Key Features Explained
Deploying the Application
Final Thoughts

1. What's in our Forex Conversion App?

Our forex conversion app will include these key features:

Convert between major currencies (USD, EUR, GBP, JPY, CAD, AUD, CHF, CNY)
Real-time exchange rates powered by Finage API

2. Setting Up The Project

In order to have access to the real-time forex data, you will need to create an account and obtain your API key at Finage. This key will be used to authenticate your requests to the Finage API and fetch live exchange rates.

We will be configuring our application for static export. This allows the application to be deployed to any static hosting platform without requiring a server. This makes deployment simple.

3. Building the Application

To get live exchange rates, we'll fetch data from the Finage API. Here's how to call the forex endpoint:

const fetchExchangeRate = async (from: string, to: string) => {
  const apiKey = process.env.NEXT_PUBLIC_API_KEY;
  const url = `https://api.finage.co.uk/convert/forex/${from}/${to}/1?apikey=${API_KEY}`;

  const response = await fetch(url);
  const data = await response.json();

  return data.rates[to];
};

More information about the Finage API can be found in their documentation.

However, when building a static web application, we'll encounter CORS (Cross-Origin Resource Sharing) issues when trying to call API directly from the browser. This is where Corsfix CORS proxy comes to the rescue. It allows us to send request directly from the browser without any server setup.

Instead of calling the API directly, we prefix the URL with the Corsfix proxy:

const fetchExchangeRate = async (from: string, to: string) => {
  const API_KEY = process.env.NEXT_PUBLIC_API_KEY || "{{FINAGE_API_KEY}}";
  const url = `https://api.finage.co.uk/convert/forex/${from}/${to}/1?apikey=${API_KEY}`;

  const response = await fetch("https://proxy.corsfix.com/?" + url);
  const data = await response.json();

  return data.rates[to];
};

We will also store our secret securely in Corsfix, so you can use the app without exposing your API key in the client JavaScript code. Learn more about how to secure your API key with Corsfix.

4. Key Features Explained

As you type in any amount, the app automatically converts to the other currency, ensuring a smooth user experience. It works by fetching the exchange rate from the Finage API and applying it to the input value. The conversion happens in real-time with the interface updating immediately to show the converted amount with proper formatting and currency symbols.

5. Deploying the Application

Since the app is configured for static export, it can be deployed to any static hosting service without server requirements. Popular hosting platforms like Cloudflare Pages, Vercel, Netlify, and GitHub Pages all support static deployments with automatic builds from your Git repository. The deployment process is typically as simple as connecting your repository and the platform will handle the build and deployment automatically whenever you push changes.

6. Final Thoughts

In this article, you've learned what it takes to build a comprehensive forex conversion application that demonstrates several important concepts:

API Integration: Using the Finage API for real-time forex data
CORS Solutions: Leveraging Corsfix to overcome browser limitations in static apps

The resulting application provides a smooth, professional user experience while demonstrating best practices for handling external APIs in static web applications. See the complete source code on GitHub.

All-in-One Resource: CORS Headers Explained

reynaldi — Wed, 04 Jun 2025 09:53:13 +0000

I'm excited to introduce CORS Headers Explained, an all-in-one resource that explains CORS headers with usage examples, common errors, and solutions. If you've ever been confused by CORS errors or struggled to implement CORS correctly, this resource is for you.

Why CORS Headers Explained?

Understanding CORS headers is essential for modern web development, but the official documentation can be overwhelming and scattered. Many developers know they need to set CORS headers but aren't sure which ones to use or how they work together. CORS Headers Explained aims to simplify this by providing a clear, structured guide to every CORS header you need to know.

What You'll Find

Our resource covers every CORS header you need to know:

Complete Header Reference: Explanations of all CORS headers including Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and more.
Practical Code Examples: Implementations examples for server and client-side code for every header.
Common Error Solutions: Clear solutions for errors and fixes for the most frequent CORS issues.

Each header page includes syntax examples, usage examples, common error solutions, and related headers to help you understand how everything fits together.

When to Use This Resource

Whether you're setting up CORS for the first time, debugging a tricky preflight request, or need to understand what each header does, CORS Headers Explained is your go-to reference. It's perfect for both beginners learning CORS fundamentals and experienced developers who need quick answers.

Visit CORS Headers Explained!

Source code is available on GitHub.

Enabling CORS in Flask

reynaldi — Thu, 22 May 2025 17:00:00 +0000

When you’re building a full-stack app with a separate frontend and a Flask backend, the browser’s Same-Origin Policy will block your API calls unless you explicitly allow them. Cross-Origin Resource Sharing (CORS) is the protocol that lets you opt-in. In this guide we will cover two common ways to get it done in Flask.

Adding CORS headers manually

Flask lets you set response headers directly, so you can choose which endpoints get which CORS rules.

Basic allow-origin

If your frontend lives at https://myapp.com, you can allow it like this:

from flask import Flask, request, jsonify, make_response

app = Flask(__name__)

@app.route("/api/hello")
def hello():
    resp = make_response(jsonify({"msg": "hi"}))
    # allow just one origin
    resp.headers["Access-Control-Allow-Origin"] = "https://myapp.com"
    return resp

Handling the pre-flight (OPTIONS) request

Whenever the browser thinks the real call might be “unsafe” (custom headers, non-GET method, etc.) it sends an OPTIONS probe first. You have to answer it with the correct headers:

@app.route("/api/hello", methods=["OPTIONS", "GET", "POST"])
def hello():
    if request.method == "OPTIONS":
        resp = make_response()
        resp.headers.update({
            "Access-Control-Allow-Origin": "https://myapp.com",
            "Access-Control-Allow-Methods": "GET, POST",
            "Access-Control-Allow-Headers": "Content-Type, X-Custom",
            "Access-Control-Allow-Credentials": "true",  # only if you need cookies / auth
        })
        resp.status_code = 204
        return resp

    # Normal GET/POST handler
    if request.method == "GET":
        resp = make_response(jsonify({"msg": "hi"}))
    elif request.method == "POST":
        data = request.get_json()
        resp = make_response(jsonify({"data": data}))
    # allow CORS for actual response
    resp.headers.update({
        "Access-Control-Allow-Origin": "https://myapp.com",
        "Access-Control-Allow-Credentials": "true"
    })
    return resp

Manual is great when you need per-endpoint logic (e.g., allow some origins only for certain users), but it gets repetitive fast.

Using the `flask-cors` library

The flask-cors library will handle the header logic for you.

pip install flask-cors

Global configuration (one-liner)

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, origins=["https://myapp.com"], supports_credentials=True)

Now every route responds with the right CORS headers and the pre-flight dance “just works.”

Fine-grained control

You can apply it to a specific blueprint or route instead:

from flask_cors import cross_origin

@app.route("/public")
@cross_origin()                      # allow all origins
def public_stuff():
    ...

@app.route("/private")
@cross_origin(origins="https://myapp.com",
              methods=["GET", "POST"],
              expose_headers=["X-Total-Count"])
def private_stuff():
    ...

Key options you’ll use most:

Option	What it does
`origins`	Accept single origin, list, or "*"
`methods`	Restrict allowed verbs
`allow_headers`	Extra request headers you expect
`expose_headers`	Response headers the browser can read
`supports_credentials`	`true` → cookies/auth tokens allowed

Conclusion

To enable CORS in your Flask project, either manually add CORS headers to specific endpoints, or use a third-party library like flask-cors to manage CORS more easily. Either way, both options will allow you to build a robust full-stack application.

What are CORS Safelisted Headers?

reynaldi — Thu, 22 May 2025 11:51:38 +0000

A big part of understanding CORS is knowing about CORS safelisted headers. These are the special headers that the browser treats differently when it comes to cross-origin requests. Knowing how they work can save you headaches when debugging CORS issues.

What are CORS Safelisted Headers?

CORS safelisted headers are split into two:

Safelisted request headers: these allow requests to be made to a different origin without a preflight OPTIONS request.
Safelisted response headers: these are headers that browsers expose to JavaScript on cross-origin responses by default.

CORS Safelisted Request Headers

CORS safelisted request headers are those that you can include in a cross-origin request without triggering a preflight OPTIONS request. A preflight request is a preliminary request sent by the browser to check if the actual request is allowed by the server. This means you can use them without worrying about the server needing to respond to an OPTIONS request first.

The safelisted request headers are:

Accept
Accept-Language
Content-Language
Content-Type
Range

And specifically for Content-Type, the only values that are allowed without triggering a preflight request are:

application/x-www-form-urlencoded
multipart/form-data
text/plain

If you send another value, like application/json, the browser will send a preflight request first to check if the server allows that content type.

CORS Safelisted Response Headers

CORS safelisted response headers, also known as simple response headers, are those that the browser exposes to JavaScript by default. This means you can access them in your JavaScript code without needing to do anything special.

The safelisted response headers are:

Cache-Control
Content-Language
Content-Length
Content-Type
Expires
Last-Modified
Pragma

By default, other response headers are not exposed to JavaScript. If you want to expose additional headers, the server must include the Access-Control-Expose-Headers header in its response. For example:

Access-Control-Expose-Headers: X-Custom-Header, X-Another-Custom-Header

Conclusion

CORS safelisted headers consist of the safelisted request headers and the safelisted response headers. The request headers are those that you can use in a cross-origin request without triggering a preflight request, while the response headers are those that the browser exposes to JavaScript by default. Understanding these headers is crucial for working with CORS and ensuring that your cross-origin requests work as expected.

How to Fetch Files From a GitHub Release (Without CORS Errors)

reynaldi — Tue, 06 May 2025 07:51:39 +0000

You’re building a web app and need to grab a ZIP or PNG straight from a GitHub release. You send a fetch() from the browser, but run into a CORS error. Let’s see why that happens and how you can fix it in two straightforward ways.

What’s the Problem?

1. Redirects break the pre-flight

The download URL GitHub gives you is just a 302 that bounces to an S3 blob. CORS pre-flights (OPTIONS requests) don’t follow redirects, so the browser stops right there.

 curl -I https://github.com/OWNER/REPO/releases/download/TAG/file.zip
 # ... HTTP/2 302 Location: https://objects.githubusercontent.com/...

2. No CORS headers on the final asset

Even if you follow the redirect manually, the S3 file itself doesn’t send Access-Control-Allow-Origin, so the browser still refuses to hand over the bytes.

 curl -I 'https://objects.githubusercontent.com/.../file.zip'
 # HTTP/2 200 (but no Access-Control-Allow-Origin)

Bottom line: GitHub’s release CDN isn’t set up for direct browser fetches.

Fixing GitHub Release CORS Errors

1. Relay Through Your Backend

Already have a server? Relay the request via your backend:

// Express example
app.get("/asset", async (req, res) => {
  const upstream = await fetch(
    "https://github.com/OWNER/REPO/releases/download/TAG/file.zip"
  );

  res.set("Content-Type", upstream.headers.get("content-type"));
  res.send(Buffer.from(await upstream.arrayBuffer()));
});

Your frontend now calls the relay endpoint, the server handles the redirect, and the browser never sees a CORS issue.

2. Use a CORS Proxy (No Backend Needed)

No server? Drop a CORS proxy in front of the GitHub URL, it follows the redirect and injects the right headers.

fetch(
  "https://proxy.corsfix.com/?https://github.com/OWNER/REPO/releases/download/TAG/file.zip"
).then((res) => res.blob());

Either route gives you a clean, CORS-friendly response in the browser.

Conclusion

GitHub release assets trigger CORS errors because the initial redirect breaks pre-flight checks and the final file lacks the needed headers. You can solve this by relaying the request through your own backend for full control or by inserting a CORS proxy for the quickest setup. Pick the approach that fits your stack and move on without CORS errors.

Need production-ready CORS proxy? Give Corsfix a try, it’s free to start and only upgrade when you go to production.

Tainted Canvas: why the browser blocks your canvas (and how to unblock it)

reynaldi — Wed, 30 Apr 2025 10:02:55 +0000

Working with the <canvas> feels simple at first, load an image, draw it, export it. But the moment that image lives on a different origin you hit an error: calls such as canvas.toDataURL() or getImageData() shows error with “Tainted canvases may not be exported.” The browser is preventing you from reading the pixels of that canvas.

Tainted canvas error

What’s with the tainted canvas?

When you draw an image fetched from another origin without proper CORS setup, the browser makes the entire canvas as “tainted.” Any attempt to read those pixels (getImageData, toBlob, toDataURL, etc.) is then blocked.

To solve this, you need to add crossOrigin="anonymous" to asks the browser to send the request in CORS mode, but the server must still reply with a matching Access-Control-Allow-Origin header.

<img src="https://example.com/image.png" crossorigin="anonymous" />

Solving the tainted canvas error

You’ve got two options to solve the tainted canvas error:

Control the server?

Add the header Access-Control-Allow-Origin: * (or your domain) and keep crossOrigin="anonymous" on your <img> tag or drawImage source.
Don’t control the server?
- Backend relay: Fetch the image in your own backend, then serve it with the right CORS header so the browser sees it as same-origin.
- CORS proxy: Use a CORS proxy that injects the header for you, ideal if you are running a static only site or don't have a backend.

  const image = new Image();
  image.crossOrigin = "anonymous";
  image.src = "https://proxy.corsfix.com/?https://example.com/image.png";
  image.onload = () => {
    const canvas = document.createElement("canvas");
    const ctx = canvas.getContext("2d");
    ctx.drawImage(image, 0, 0);
    const dataUrl = canvas.toDataURL();
    console.log(dataUrl);
  };

Conclusion

A tainted canvas is just the browser’s way of preventing you from accessing a canvas that contains cross-origin data. Tell the browser to expect CORS (crossOrigin="anonymous") and tell the server to allow it (Access-Control-Allow-Origin). If you can’t modify the server, relay the image through your backend or use a CORS proxy. Need something production-ready? Give Corsfix a spin, it’s free to start and only costs when you scale.

Forem: reynaldi

How to Set the Host Header in Fetch (JavaScript)

Quick Solution

Why Browsers Block the Host Header

How a Proxy Solves the Problem

When Do You Need to Set the Host Header?

Best Practices

Only Override What You Need

Handle Errors Gracefully

Conclusion

Building a File Sharing App with Puter.js

Key Features

Getting Started

Building the App

Creating a Hosted Subdomain

Uploading the File

Generating the Public Link

Conclusion

Building an AI-Powered RAG Application with Puter.js

Key Features

Getting Started

Building the App

Crawling the Website

Managing Sites with Puter Key-Value Store

Adding Search for Website Content

Adding AI Chat with Function Calling

Conclusion

Why Most APIs Don't Enable CORS?

Why Most APIs Don't Enable CORS

Server-to-Server Communication by Design

Preventing API Token Leakage

Rate Limiting and Access Control

What It's NOT Protecting

CORS Is Not A Protection For Session Hijacking

Where Does a CORS Proxy Fit Here?

Conclusion

Building an HTML-to-Image Website Screenshot Tool

How Screenshot Tools Typically Work

Alternative: In-Browser HTML to Image

Getting the website HTML

Putting It All Together

Conclusion

How Much Bandwidth Do You Need for an API in 2025?

Websites Are Heavy

APIs Are a Different Story

Estimate: APIs Are 20x Lighter Than Webpages

What This Means for Bandwidth Planning

Conclusion

Building a Real-Time Forex Rate Conversion App with Finage API

Table of Contents

1. What's in our Forex Conversion App?

2. Setting Up The Project

3. Building the Application

4. Key Features Explained

5. Deploying the Application

6. Final Thoughts

All-in-One Resource: CORS Headers Explained

Why CORS Headers Explained?

What You'll Find

When to Use This Resource

Enabling CORS in Flask

Adding CORS headers manually

Basic allow-origin

Handling the pre-flight (OPTIONS) request

Using the flask-cors library

Global configuration (one-liner)

Fine-grained control

Conclusion

What are CORS Safelisted Headers?

What are CORS Safelisted Headers?

CORS Safelisted Request Headers

CORS Safelisted Response Headers

Conclusion

How to Fetch Files From a GitHub Release (Without CORS Errors)

What’s the Problem?

1. Redirects break the pre-flight

2. No CORS headers on the final asset

Fixing GitHub Release CORS Errors

1. Relay Through Your Backend

2. Use a CORS Proxy (No Backend Needed)

Using the `flask-cors` library