DEV Community: Brandon Sooknanan

Going from W-2 to 1099 as a developer: the tax math nobody puts in the offer

Brandon Sooknanan — Sun, 15 Nov 2026 01:55:45 +0000

A lot of developers get their first contract offer the same way: a recruiter says "$90 an hour on a 1099" and it sounds like a raise over a $150,000 salary. Sometimes it is. Often it isn't, and the difference is mostly tax and benefits that nobody spells out.

This is the short version of a longer guide I wrote, 1099 vs W-2: how the taxes really differ, with US federal numbers for 2026.

What actually changes

The income tax brackets are identical for W-2 and 1099 income. Three things change:

Who pays the payroll tax. As an employee you pay 7.65% for Social Security and Medicare and your employer quietly pays another 7.65%. As a contractor you pay both halves: 15.3% self-employment tax, on 92.35% of your profit.
When you pay. Nobody withholds anything from a contractor. The IRS expects quarterly estimated payments in April, June, September and January, and charges an underpayment penalty if you wait until April to pay it all.
What you can deduct. A contractor deducts real business costs before tax: the laptop, a monitor, software subscriptions, part of a phone bill, a home office. An employee can't deduct unreimbursed work expenses on a federal return.

The payroll tax gap, in dollars

On $150,000 of W-2 salary you pay about $11,475 in Social Security and Medicare tax.

On $150,000 of contract profit you pay about $21,194 in self-employment tax. You get half of that back as a deduction from income, which saves a few thousand dollars of income tax, but you're still well behind.

So before thinking about anything else, a contract rate needs to be roughly 7.65% higher than the salary just to cover the employer's half of payroll tax. Then add what the salaried job included:

health insurance (often $500 to $1,500 a month on your own),
a 401(k) match,
paid holidays, vacation and sick days (contract hours you don't work, you don't bill),
equipment and software the company paid for.

That's why the common rule of thumb is 25% to 40% more than the salary, and why $90/hour can come out about even with, or below, a $150,000 salary once you count roughly 1,800 billable hours a year instead of 2,080 and pay for your own benefits.

What helps on the 1099 side

It isn't all downside. Contractors get some things employees don't:

The QBI deduction. Most sole proprietors can deduct up to 20% of their business profit from taxable income. At typical developer incomes it's worth thousands. (How it works)
Bigger retirement contributions. A solo 401(k) or SEP IRA lets you shelter far more than most employer plans would, and it's deductible.
Health insurance premiums are deductible on Schedule 1 if you're not eligible for an employer plan (including a spouse's). (Details)
Business expenses. That new laptop is a deduction, not a cost you eat.

The habit that makes it work

The single biggest mistake new contractors make is spending the whole invoice. A simple fix: every time a client pays you, move a fixed percentage into a separate savings account for tax. For most freelance developers that's somewhere around 25% to 35%, depending on income and state. There's a table by income in how much to set aside for taxes.

If you'd rather compute it than guess, there's a free quarterly tax calculator that runs entirely in the browser: enter your expected profit and it shows the self-employment tax, income tax and what each quarterly payment should be.

Are you really a contractor?

One more thing worth knowing: the label on your contract doesn't decide it. The IRS looks at behavioral control (do they tell you how and when to work?), financial control (whose equipment, can you take other clients?) and the relationship (benefits, an indefinite engagement). A "contractor" who works fixed hours on the company's laptop for one client indefinitely may legally be an employee. If you think you've been misclassified, Form SS-8 asks the IRS to decide, and Form 8919 lets you pay only the employee's share of payroll tax.

The full guide has the side-by-side table and the sources. This is general information, not tax advice, and state taxes are on top of all of it.

Making a calculator other sites can embed, on a fully static site

Brandon Sooknanan — Sun, 15 Nov 2026 01:49:39 +0000

I run a small site for freelancers, Paid & Filed, and its most useful page is a free 1099 tax calculator that works out quarterly estimated tax. Bloggers, coworking spaces and accountants who write for freelancers kept wanting to put it on their own pages, so I made it embeddable.

The site is a static Next.js export served from a Cloudflare Worker: no backend, no API keys, no per-site accounts. Here's how the embed works within those limits.

The embed is just a second route

The calculator is one React component. The embeddable version is a separate route, /embed/quarterly-tax-calculator/, that renders the same component without the site header, footer or analytics:

export const metadata: Metadata = {
  title: '1099 tax calculator for 2026',
  robots: { index: false, follow: true },
};

export default function EmbeddedCalculator() {
  return (
    <div className="px-3 pb-5 pt-4">
      <Calculator embedded />
      <p className="mt-5 text-center text-[13px]">
        Free <a href="https://paidandfiled.com/quarterly-tax-calculator/" target="_blank" rel="noopener">1099 tax calculator</a> by Paid & Filed.
      </p>
      <EmbedHeight />
    </div>
  );
}

Two decisions in there:

The embed route is noindex. It's set in the page metadata and again as an X-Robots-Tag header for /embed/*, so search engines send people to the real calculator page rather than a stripped-down duplicate. follow stays on, so the links inside still count.
No trackers in the frame. A layout check turns off the analytics beacon and the ad-network tag on embed routes. Someone embedding a calculator shouldn't be adding third-party tracking to their own visitors without knowing it.

Auto-height without a library

Iframes don't size themselves to their content. A fixed height either cuts off the results or leaves a big gap, and this calculator changes height as you open sections.

The embedded page reports its height to the parent whenever it changes:

export function EmbedHeight() {
  useEffect(() => {
    const main = document.querySelector('main');
    if (window.parent === window || !main) return; // not in a frame
    const send = () =>
      window.parent.postMessage({ pfHeight: Math.ceil(main.getBoundingClientRect().height) }, '*');
    const ro = new ResizeObserver(send);
    ro.observe(main);
    send();
    return () => ro.disconnect();
  }, []);
  return null;
}

It measures <main>, not document.body. Inside an iframe, the body is always at least as tall as the frame itself, so measuring it means the frame can grow but never shrink.

It posts to '*' because it can't know who embedded it, and that's fine here because the message is a single number and nothing sensitive.

The host page gets one line of script as part of the embed code:

<iframe src="https://paidandfiled.com/embed/quarterly-tax-calculator/"
        title="1099 tax calculator for 2026" loading="lazy"
        style="width:100%;height:1650px;border:0"></iframe>
<p style="font-size:14px">1099 tax calculator by <a href="https://paidandfiled.com/quarterly-tax-calculator/">Paid &amp; Filed</a></p>
<script>
addEventListener('message', function (e) {
  if (e.origin !== 'https://paidandfiled.com' || !e.data || !e.data.pfHeight) return;
  document.querySelectorAll('iframe[src^="https://paidandfiled.com/embed/"]').forEach(function (f) {
    if (f.contentWindow === e.source) f.style.height = e.data.pfHeight + 'px';
  });
});
</script>

The receiving side is where the checks belong:

e.origin must be the calculator's origin, so another frame on the page can't resize things.
f.contentWindow === e.source matches the message to the exact iframe that sent it, so two embeds on one page don't fight.
The script is optional. Without it the iframe keeps its fixed height and scrolls, which is ugly but works. Plenty of CMSs strip <script> from posts, so the fallback matters.

The credit link is a plain brand link

The <p> under the iframe is an ordinary link in the host page that credits the tool by name. It's tempting to make that link anchor text like "best quarterly tax calculator", but Google's spam policies call out keyword-rich links in widgets and embeds that are distributed across many sites. A plain brand-name link is honest attribution, and the host can remove it or add rel="nofollow" if they prefer. The embed works the same either way.

Privacy is easy when there's no server

Because the calculator is pure client-side math on figures from the IRS, nothing the visitor types leaves the browser, inside the iframe or out. That's a big part of why people are comfortable embedding it: no data processing agreement, no cookie banner implications from the frame itself.

Result

The embed code lives in a copy box on the calculator page, free to use. If you've built embeddable widgets on static hosting and handled auto-height differently, I'd like to hear how in the comments.

Parsing bank statement PDFs in the browser, with a CSP that proves nothing gets uploaded

Brandon Sooknanan — Sun, 15 Nov 2026 01:49:18 +0000

People who freelance often can't get a CSV out of their bank. Some banks only give PDF statements, others limit downloads to 90 days, and a few dropped CSV and QFX exports entirely. But every bookkeeping spreadsheet wants rows of Date, Description, Amount.

The usual fix is an online converter, which means uploading a year of bank statements to a stranger's server. I didn't want to ask anyone to do that, so the converter I built for Paid & Filed runs entirely in the browser tab: paidandfiled.com/bank-statement-converter. This post covers the three parts that were harder than I expected.

1. Turning pdf.js text runs back into lines

page.getTextContent() doesn't give you lines. It gives you runs of text, each with a transform matrix, in whatever order the PDF generator wrote them. A single statement row like

03-14  ACH DEPOSIT CLIENT CO       1,250.00     4,310.27

can arrive as six runs, out of order, with the minus sign of a debit split into its own run.

So the first step rebuilds lines geometrically: sort by baseline (transform[5], top to bottom) then x position, group runs whose baselines are within 2 points, and join runs that physically touch without a space so a word pdf.js split stays whole.

export function itemsToLines(items: PdfTextItem[]): string[] {
  const runs = items
    .filter((i) => i.str?.trim() && i.transform)
    .map((i) => ({ x: i.transform![4], y: i.transform![5], w: i.width ?? 0, s: i.str! }))
    .sort((a, b) => b.y - a.y || a.x - b.x);

  const lines: { y: number; runs: typeof runs }[] = [];
  for (const run of runs) {
    const last = lines[lines.length - 1];
    if (last && Math.abs(last.y - run.y) <= 2) last.runs.push(run);
    else lines.push({ y: run.y, runs: [run] });
  }

  return lines.map(({ runs }) => {
    let text = '';
    let end = -Infinity;
    for (const run of runs.sort((a, b) => a.x - b.x)) {
      const touching = run.w > 0 && end > -Infinity && run.x - end < 0.6;
      text += (text && !touching ? ' ' : '') + run.s;
      end = run.w > 0 ? run.x + run.w : -Infinity;
    }
    return text.replace(/\s+/g, ' ').trim();
  }).filter(Boolean);
}

A page that comes back with fewer than 40 non-space characters is a scan or a photo. There's no text layer to read, so the UI says so instead of returning an empty file.

2. One generic reader instead of a template per bank

The obvious design is a template per bank. I started from code that worked that way, and it falls apart quickly: the same bank changes layout between checking and savings, between years, and between the web download and the mailed PDF.

The generic rule turned out to be simple. A transaction line starts with a date and ends with one or two amounts. If there are two, the last one is the running balance. Everything in between is the description. Dates can be 03/14, 03-14, Mar 14 or 14 Mar 2026, and when a row has no year it comes from the statement period printed in the header, with care for December statements that run into January.

The hard part is the sign. Bank PDFs show direction in at least five ways: separate debit and credit columns (which collapse into one column once you've flattened the page to text), a trailing minus (45.10-), CR and DR codes, section headings like "Deposits and other credits", or nothing at all. So direction is decided in priority order:

let direction: 'in' | 'out' | null = null;

// 1. The running balance: if it went up by exactly this amount, it's money in.
if (running != null && row.balance != null) {
  const delta = cents(row.balance) - cents(running);
  const v = cents(row.value);
  if (delta === v) direction = isCard ? 'out' : 'in';
  else if (delta === -v) direction = isCard ? 'in' : 'out';
}
// 2. CR / DR / DEP / WD codes next to the amount.
if (!direction && row.marker) direction = row.marker;
// 3. A printed sign (a minus means money out on a bank statement, a payment on a card).
if (!direction && row.printedSign) direction = /* ... */;
// 4. The section heading the row sits under.
if (!direction && row.heading) direction = row.heading;
// 5. Give up, call it money out, and flag it for the user.
if (!direction) { direction = 'out'; row.guessed = true; }

Two details matter here:

Everything is compared in integer cents. 0.1 + 0.2 problems are real when you're summing 300 rows.
Credit cards run backwards. A purchase raises the balance on a card and lowers it on a checking account, so the reader decides "card or bank" first. It looks for phrases like "minimum payment due" or "credit limit", but only before the first transaction row. A savings statement with a line-of-credit footer under it was read as a card, with every sign flipped, until that rule went in.

3. The balance check

Statements print an opening and a closing balance. After parsing, the reader checks that opening plus money in minus money out equals the closing balance, to the cent. The UI shows a green "matches the statement" or the exact difference. That one check catches nearly every parsing bug: a row that wrapped onto two lines, a page footer read as a transaction, a sign guessed wrong.

When some rows had to be guessed and the totals don't add up, it tries one more thing: if flipping all the guessed rows to money in makes the balance match, it does that. It's a cheap heuristic that fixed a whole class of statements with unlabeled credit columns.

On real statements from one credit union (29 PDFs covering two years of checking, savings and loan statements), every checking statement matched to the cent on the first run. That test also exposed the card/savings bug above and the fact that loan statements have nothing to convert, so they now get their own message instead of a silent empty result.

Proving it never uploads anything

"Your file never leaves your browser" is easy to write and impossible for a visitor to verify. So the page carries a Content Security Policy that makes it true at the browser level. The site is static files on a Cloudflare Worker, and this lives in _headers:

/bank-statement-converter/
  Content-Security-Policy: connect-src 'self' https://cloudflareinsights.com; form-action 'self'

connect-src covers fetch, XMLHttpRequest, WebSockets, sendBeacon and EventSource, so the only place this page can send data is its own origin (which serves static files and has no upload endpoint) and the privacy-friendly analytics beacon. A future change that accidentally added a third-party script with tracking would be blocked by the browser, and it would show up in DevTools as a CSP violation.

A few things I had to get right for that to hold:

pdf.js is self-hosted (copied from node_modules into /public/pdfjs/<version>/ at build time), worker included, so loading it isn't a cross-origin request.
isEvalSupported: false in getDocument, which keeps pdf.js from compiling fonts with new Function().
Links into the page are plain <a> tags, not client-side router links. A client-side navigation never loads the page fresh, so the browser never applies the page's own CSP header. A full page load does.
The Pinterest tag the rest of the site uses is skipped on this path.

Password-protected PDFs work too. pdf.js throws a PasswordException and the UI asks for the password, which goes straight back into getDocument and nowhere else.

The output

The result downloads as CSV or Excel, or copies as tab-separated text so a paste into column A of a spreadsheet fills three columns. The .xlsx is written in the browser as well, with a small zip writer, so nothing round-trips to a server for that either.

If you want to try it, there's a "made-up statement" button on the converter page, so you don't need to feed it your own bank PDF to see how it works. It's free with no sign-up. Paid & Filed is the small business I run that makes a self-employed tax workbook, and the converter exists because buyers kept getting stuck at the "now paste your bank CSV" step.

Questions about the parser or the CSP approach are welcome in the comments.