DEV Community: Віталік Бакута

The math behind Etsy fees: a tiny JavaScript model (and why cheap items hurt)

Віталік Бакута — Fri, 13 Nov 2026 01:19:36 +0000

Marketplace fees look simple until you try to put them in code. Some are percentages, some are fixed, they apply to different bases, and one of them depends on how the buyer found you.

I built Fee Math, a set of free fee and profit calculators for Etsy, Amazon, eBay, TikTok Shop and payment processors. Etsy was the first one, and it's a nice small modelling exercise. Here is the whole thing in about 25 lines of JavaScript.

Rates below are Etsy's US defaults as last checked in October 2026. Fees change and differ by country, so always confirm on Etsy's fee page before relying on them. This is not financial advice.

The fee lines

For a typical US shop, one order can involve:

Fee	Rate	Charged on
Listing fee	$0.20	per listing published or renewed
Transaction fee	6.5%	item price + shipping
Payment processing	3% + $0.25	item price + shipping + tax
Offsite Ads (only if the sale came from an ad)	15% (12% for shops over $10k/year), capped at $100	the order
Currency conversion (only if currencies differ)	2.5%	the order

Two details people miss:

Fees apply to shipping too. Charging $5 for shipping costs you about $0.48 in fees.
The fixed parts ($0.25 + $0.20) don't care about price, which matters a lot for cheap items (more on that below).

The model

const RATES = {
  transaction: 0.065,
  processing: 0.03,
  processingFixed: 0.25,
  listing: 0.20,
  offsiteAds: 0.15,
  offsiteAdsCap: 100,
  conversion: 0.025,
};

const round = (x) => Math.round(x * 100) / 100;

function etsyFees({ price, shipping = 0, tax = 0, fromOffsiteAd = false, conversion = false }) {
  const sale = price + shipping;

  const lines = {
    transaction: sale * RATES.transaction,
    processing: (sale + tax) * RATES.processing + RATES.processingFixed,
    listing: RATES.listing,
    offsiteAds: fromOffsiteAd ? Math.min(sale * RATES.offsiteAds, RATES.offsiteAdsCap) : 0,
    conversion: conversion ? sale * RATES.conversion : 0,
  };

  for (const k in lines) lines[k] = round(lines[k]);
  lines.total = round(Object.values(lines).reduce((a, b) => a + b, 0));
  return lines;
}

Each line is rounded to cents on its own, because that's how fees show up on a statement. If you build something bigger, store money as integer cents from the start and avoid float surprises altogether.

Example 1: a $25 item with $5 shipping

etsyFees({ price: 25, shipping: 5 });
// { transaction: 1.95, processing: 1.15, listing: 0.2,
//   offsiteAds: 0, conversion: 0, total: 3.3 }

Revenue is $30, fees are $3.30 (11%). If the item costs $8 to make and $4.50 to ship, profit is:

30.00 - 3.30 - 8.00 - 4.50 = $14.20  (47% margin)

Now the same order, but the buyer came through an Offsite Ad:

etsyFees({ price: 25, shipping: 5, fromOffsiteAd: true }).total; // 7.8

Fees jump to $7.80 (26% of revenue) and profit drops to $9.70. Same product, same buyer, one third less profit. That's why it's worth modelling Offsite Ads as a scenario, not ignoring it.

Example 2: why cheap items hurt

Look at fees as a share of the sale with free shipping:

Item price	Total fees	Share of sale
$10	$1.40	14.0%
$25	$2.83	11.3%
$100	$9.95	10.0%

The percentages are the same at every price; the $0.45 of fixed fees is what pushes the share up for low prices. Stickers, digital downloads and small accessories feel this the most. Bundling ("set of 3") is often the easiest fix.

Example 3: solving for the price you need

The more useful question is usually the reverse: what should I charge to make $X? With free shipping, no tax and no ads, fees are 0.095 × price + 0.45, so:

price = (costs + targetProfit + 0.45) / (1 - 0.065 - 0.03)

function priceForProfit(costs, target, adsRate = 0) {
  const pct = RATES.transaction + RATES.processing + adsRate;
  const fixed = RATES.processingFixed + RATES.listing;
  return Math.ceil(((costs + target + fixed) / (1 - pct)) * 100) / 100;
}

priceForProfit(12.5, 10);        // 25.36
priceForProfit(12.5, 10, 0.15);  // 30.4  (if the sale comes from an Offsite Ad)

So to keep $10 on an item that costs you $12.50 including shipping, list it at about $25.36, or $30.40 if you want the same profit even on ad-driven sales. (The ad cap of $100 only kicks in for orders above roughly $667, so it's safe to ignore here.)

What this model leaves out

To keep it honest, it doesn't include income tax, VAT on Etsy's own fees, regulatory operating fees in some countries, Etsy Ads (on-site), subscriptions or shipping label costs. Payment processing rates also differ by country: for example 4% + £0.20 in the UK.

Try it without code

If you sell on Etsy and don't want to maintain a script, the Etsy fee calculator on Fee Math does all of the above, shows every fee as a separate line, supports other countries and Offsite Ads, and gives you a shareable link or PDF. There are also calculators for Amazon FBA, eBay, TikTok Shop and PayPal. The sources and "last checked" dates for every rate are on the methodology page.

Which marketplace has the most confusing fee structure in your experience? I'm deciding what to model next.

Convert images in the browser without uploading them (Canvas, createImageBitmap and WebAssembly)

Віталік Бакута — Fri, 13 Nov 2026 01:13:05 +0000

Most "free online converters" work the same way: you upload a file, a server converts it, you download the result. For a holiday photo that's fine. For a scanned passport, a contract or a client's design file, it's an unnecessary risk.

While building FormatMath I wanted the opposite: the file never leaves the device. Modern browsers can do most of this work on their own. Here is how, plus the gotchas I hit along the way.

The basic pipeline: decode → draw → encode

For formats the browser already understands (JPEG, PNG, WebP, GIF, BMP, often AVIF), conversion is three steps:

Decode the file into a bitmap with createImageBitmap().
Draw it onto a canvas.
Encode the canvas to the target format.

async function convertImage(file, type = 'image/jpeg', quality = 0.9) {
  const bitmap = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
  const ctx = canvas.getContext('2d');

  // JPEG has no transparency: paint a white background first,
  // otherwise transparent pixels turn black.
  if (type === 'image/jpeg') {
    ctx.fillStyle = '#fff';
    ctx.fillRect(0, 0, canvas.width, canvas.height);
  }

  ctx.drawImage(bitmap, 0, 0);
  bitmap.close(); // free memory early

  return canvas.convertToBlob({ type, quality });
}

Wiring it to a file input and a download link:

input.addEventListener('change', async () => {
  const file = input.files[0];
  const blob = await convertImage(file, 'image/webp', 0.85);

  const a = document.createElement('a');
  a.href = URL.createObjectURL(blob);
  a.download = file.name.replace(/\.[^.]+$/, '') + '.webp';
  a.click();
  setTimeout(() => URL.revokeObjectURL(a.href), 1000);
});

No fetch, no FormData, no server. Open DevTools → Network while converting and you'll see nothing go out. That's also the easiest way to verify any tool that claims "we don't upload your files".

Gotcha 1: the browser may silently ignore your format

If the browser can't encode the type you asked for, convertToBlob() / toBlob() doesn't throw. It quietly returns a PNG. Always check the result:

if (blob.type !== type) {
  console.warn(`This browser can't encode ${type}, got ${blob.type}`);
}

Encoder support varies more than decoder support, especially for WebP and AVIF output. When you need guaranteed output, ship an encoder compiled to WebAssembly (for example the codecs from the Squoosh project) instead of relying on the canvas.

Gotcha 2: HEIC needs WebAssembly

iPhone photos are HEIC by default. Safari can decode them natively, but Chrome and Firefox generally can't, so createImageBitmap() will reject. The fix is a decoder compiled to WebAssembly, typically based on libheif:

Read the file as an ArrayBuffer.
Decode it in WASM to raw RGBA pixels.
Put the pixels into ImageData and continue with the canvas pipeline above.

The same idea works for camera RAW, TIFF, PSD and other formats the browser doesn't know: compile a decoder, get pixels, reuse the encoder.

Gotcha 3: metadata disappears (usually a good thing)

Drawing to a canvas keeps only pixels. EXIF data, including GPS location, camera model and timestamps, is dropped. For privacy that's a feature: a photo re-encoded this way no longer leaks where it was taken.

Two side effects to handle:

Orientation. Phones often store a rotation flag instead of rotating pixels. Current browsers apply it in createImageBitmap() by default (imageOrientation: 'from-image'), but test with a portrait phone photo anyway.
Colour profiles. Wide-gamut images (Display P3) can look slightly duller after conversion if you don't handle colour space. For most web use it's acceptable; for print work, it isn't.

If you want to keep metadata, you have to read it before decoding and write it back into the new file with a small EXIF library.

Gotcha 4: big images and memory

Canvas size is limited, and the limit differs by browser and device. Mobile Safari is the strictest. A 50-megapixel RAW file can fail where a 12 MP photo works fine. What helps:

Do the work in a Web Worker with OffscreenCanvas so the UI doesn't freeze.
Process files one at a time in batch mode, and call bitmap.close() / revoke object URLs as soon as you're done.
Offer a downscale option for very large inputs.

What about PDFs?

Same philosophy, different libraries:

PDF → image: render each page with pdf.js into a canvas, then encode as above.
Merge, split, rotate: pdf-lib manipulates the document structure directly in JavaScript, without re-rendering pages.
Compress: usually means re-encoding embedded images at lower quality, which brings you back to the canvas or a WASM encoder.

Is client-side always better?

Not always. Server-side conversion still wins for very large batches, exotic formats with no WASM build, or when you need identical output on every device. But for everyday tasks like HEIC → JPG, PNG → WebP or merging two PDFs, the browser is more than capable, and the privacy story becomes "we never had your file" instead of "trust us, we delete it".

If you just want the tools rather than the code, they're all on FormatMath: HEIC to JPG, PDF to JPG, Merge PDF and a set of developer tools. Everything runs locally in your browser.

Have you built something client-side that people assumed needed a server? I'd like to hear about it in the comments.

Can ChatGPT, Claude and Perplexity actually crawl your site? A 10-minute check

Віталік Бакута — Fri, 13 Nov 2026 01:12:13 +0000

More and more people find websites through AI assistants instead of a classic list of blue links. If an assistant can't fetch your pages, it can't quote them, summarize them or link to them. The annoying part: you can be blocked without ever deciding to block anyone.

I ran into this while building BotReady, a set of free checks for AI crawler access. Below is the manual version of the same checklist, so you can verify your own site with nothing more than a browser and a terminal.

1. Know which bots you are dealing with

AI companies usually run several user agents, and they do different jobs. Blocking one does not block the others.

Company	Training crawler	Search / indexing	User-triggered fetch
OpenAI	`GPTBot`	`OAI-SearchBot`	`ChatGPT-User`
Anthropic	`ClaudeBot`	`Claude-SearchBot`	`Claude-User`
Perplexity	—	`PerplexityBot`	`Perplexity-User`
Google	`Google-Extended` (robots.txt token, not a separate bot)	`Googlebot`	—
Apple	`Applebot-Extended` (token)	`Applebot`	—
Common Crawl	`CCBot`	—	—

The practical takeaway: "I don't want my content used for training" and "I want to show up when someone asks ChatGPT about my product" are two different robots.txt decisions. Many sites block everything with one rule and lose visibility they actually wanted.

Also note that user-triggered fetchers (a person pasting your URL into a chat) are treated differently by some vendors and may not follow robots.txt the same way a crawler does. Check each vendor's docs for the current behaviour.

2. Read your robots.txt like a bot would

Open https://yourdomain.com/robots.txt and look for three things:

A blanket User-agent: * + Disallow: / (blocks everyone, including AI bots).
Explicit Disallow rules for the bots above, often added by a CMS plugin or a security preset you forgot about.
Groups that accidentally match. A bot follows the most specific User-agent group that matches it and ignores the rest, so a GPTBot group without an Allow can override your generous * group.

A common "search yes, training no" setup looks like this:

# Allow AI search / answer engines
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Allow: /

# Opt out of model training
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
Disallow: /

User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

This is a policy choice, not a recommendation: decide what you want, then make the file say exactly that.

3. Check the layer robots.txt can't see: your CDN or firewall

This is the one that surprises people most. robots.txt is a polite request. A CDN or WAF rule is a hard block that returns 403 before your server is even involved.

Cloudflare has a one-click setting to block AI bots, and newer zones can have AI crawler blocking turned on by default. Look in the dashboard under the bots / AI crawl control section.
Hosting "bot protection" and security plugins sometimes challenge any unknown user agent with a JavaScript or CAPTCHA page. A crawler can't solve that, so it sees an empty page.

A quick first test from your terminal:

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
  https://yourdomain.com/

Repeat with ClaudeBot, PerplexityBot, etc. 200 is good; 403, 429 or 503 deserves a look.

One caveat: spoofing the user agent from your laptop is not the same as a real crawler request. Many firewalls verify bots by IP range, so a fake GPTBot may be blocked while the real one is allowed, or the other way around. The test tells you whether UA-based rules exist; your logs tell you the truth (step 5).

4. Make sure there is something to read without JavaScript

Most AI crawlers fetch raw HTML and do not run your JavaScript. If your page is a client-side SPA, they may get an empty <div id="root"></div>.

curl -s https://yourdomain.com/your-page | grep -i "a sentence from your page"

If the text you care about isn't in the raw HTML, consider SSR, static generation or prerendering for content pages. While you're there, check that the page has a clear <title>, one <h1>, a meta description and valid structured data. These help any machine reader, not only AI ones.

5. Look at your server logs

This is the only place you see what really happened. Search access logs for the bot names:

grep -Ei "gptbot|oai-searchbot|chatgpt-user|claudebot|claude-searchbot|claude-user|perplexitybot|perplexity-user" access.log \
  | awk '{print $9}' | sort | uniq -c

That prints the status codes each bot received. Lots of 403s mean something is blocking them. No hits at all may mean they never got past the CDN (check CDN logs) or simply haven't discovered the site yet. Anyone can fake a user agent, so verify important hits against the vendor's published IP ranges.

6. Optional: llms.txt

/llms.txt is a proposed Markdown file that gives AI tools a short map of your most important pages. It's not a standard that crawlers are required to use, and it doesn't replace robots.txt or a sitemap. It's cheap to add, though, and handy for documentation sites.

The short version

Decide separately on training and AI search access.
Make robots.txt say exactly that, per user agent.
Check the CDN/WAF, because it overrides everything else.
Serve real content in the HTML.
Confirm in your logs.

If you'd rather not do it by hand, the AI Crawler Checker and AI Visibility Checker on BotReady run these checks for a URL in one go, and the robots.txt generator writes the per-bot rules for you. Free, no sign-up for the first checks.

What did you find on your own site? I'm curious how many people discover a forgotten firewall rule. 👀