DEV Community: Jorge

Your presigned PUT URL for a 200 KB avatar also accepts 3 GB

Jorge — Wed, 07 Oct 2026 18:28:26 +0000

The standard advice for letting users upload files is: keep the bucket private,
have your server mint a presigned URL, let the browser PUT straight to S3. Your
credentials never reach the client and the bytes never touch your server. That
part is correct and most tutorials get it right.

Here is the part they leave out. A presigned PUT URL signs the method, the key
and the expiry. It does not constrain the body. You minted that URL for a
200 KB avatar. A client can send three gigabytes to it instead, and S3 will
take them, up to the 5 GB single-PUT ceiling.

Nothing is broken. That is what a presigned PUT is. What you published is an
authenticated, unmetered write into a bucket you pay for, and an attacker does
not need to break anything: they use the URL you gave them, repeatedly, with
large bodies. Your storage bill is the attack surface.

The defence that does not work

Almost everyone's first fix is to pass the length to the signer:

// Looks right. Does nothing.
const url = await getSignedUrl(s3, new PutObjectCommand({
  Bucket: 'your-bucket',
  Key: key,
  ContentLength: 204800,
}), { expiresIn: 300 });

Check what came back. If X-Amz-SignedHeaders in that URL says host and
nothing else, the signature does not cover the length. The client declares
whatever it likes in its own Content-Length and S3 has nothing to compare it
against.

This is the whole trap: passing a value to a signer is not the same as signing
it. Most SDK presign helpers produce exactly that URL, and it looks like it
worked.

Fix one: the POST policy

A presigned POST is a different operation, not a variant of PUT. It carries a
policy document, signed, that S3 evaluates before the object exists:

// @aws-sdk/s3-presigned-post
const { url, fields } = await createPresignedPost(s3, {
  Bucket: 'your-bucket',
  Key: `u/${userId}/${crypto.randomUUID()}`,
  Conditions: [
    ['content-length-range', 1, 2 * 1024 * 1024],   // enforced at the door
    ['starts-with', '$Content-Type', 'image/'],
  ],
  Expires: 60,
});

The browser posts multipart/form-data with those fields plus the file.
Anything outside the policy never becomes an object. If you are on AWS and can
live with a multipart form on the client, stop here, this is the answer.

Two reasons you might not be able to.

The client gets more complicated. fetch(url, { method: 'PUT', body: file })
becomes building a FormData with fields in the right order, which is most of
why tutorials teach PUT in the first place.

And Cloudflare R2 does not implement presigned POST at all. It is absent
from R2's S3 compatibility tables and attempts come back InvalidArgument. If
your bucket is R2, the code above is not available to you.

Fix two: sign the length into the PUT

This is the one I could not find written down anywhere, and we needed it
because our default store is R2.

SigV4 covers every header named in X-Amz-SignedHeaders. So put
content-length in there. The store recomputes the signature from the headers
it actually received: a client issued a URL for 204,800 bytes that sends three
gigabytes produces a different canonical request, a different signature, and a
403 with nothing stored.

Here is a complete presign, no SDK and no dependencies, about sixty lines:

import { createHmac, createHash } from 'node:crypto';

const enc = (s) => encodeURIComponent(s).replace(/[!'()*]/g, (c) =>
  `%${c.charCodeAt(0).toString(16).toUpperCase()}`);
const canonicalQuery = (q) => Object.keys(q).sort()
  .map((k) => `${enc(k)}=${enc(q[k])}`).join('&');
const sha256 = (s) => createHash('sha256').update(s, 'utf8').digest('hex');

export function presignPut({
  accessKeyId, secretAccessKey, sessionToken,
  endpoint, bucket, region = 'auto',
  key, contentLength, contentType, expiresInSeconds = 300, now = new Date(),
}) {
  const amzDate = now.toISOString().replace(/[-:]|\.\d{3}/g, '');
  const dateStamp = amzDate.slice(0, 8);
  const scope = `${dateStamp}/${region}/s3/aws4_request`;

  const base = new URL(endpoint);
  const canonicalUri = `/${bucket}/${key.split('/').map(enc).join('/')}`;

  // THE WHOLE FEATURE IS THIS LINE.
  const signedHeaders = 'content-length;content-type;host';

  const query = {
    'X-Amz-Algorithm': 'AWS4-HMAC-SHA256',
    'X-Amz-Credential': `${accessKeyId}/${scope}`,
    'X-Amz-Date': amzDate,
    'X-Amz-Expires': String(expiresInSeconds),
    'X-Amz-SignedHeaders': signedHeaders,
  };
  if (sessionToken) query['X-Amz-Security-Token'] = sessionToken;

  const canonicalRequest = [
    'PUT',
    canonicalUri,
    canonicalQuery(query),
    // Sorted by lowercase header name. content-length < content-type < host,
    // which happens to be the order you want anyway.
    `content-length:${contentLength}\ncontent-type:${contentType}\nhost:${base.host}\n`,
    signedHeaders,
    // Correct, and not a weakness: the body does not exist at signing time, so
    // its hash cannot be signed. Its LENGTH still is.
    'UNSIGNED-PAYLOAD',
  ].join('\n');

  const stringToSign = ['AWS4-HMAC-SHA256', amzDate, scope, sha256(canonicalRequest)].join('\n');
  let k = Buffer.from(`AWS4${secretAccessKey}`, 'utf8');
  for (const part of [dateStamp, region, 's3', 'aws4_request']) {
    k = createHmac('sha256', k).update(part, 'utf8').digest();
  }
  query['X-Amz-Signature'] = createHmac('sha256', k).update(stringToSign, 'utf8').digest('hex');

  return {
    url: `${base.origin}${canonicalUri}?${canonicalQuery(query)}`,
    headers: { 'content-length': String(contentLength), 'content-type': contentType },
  };
}

The client must then send both headers verbatim:

await fetch(url, { method: 'PUT', headers, body: file });

That is the cost, and it is smaller than switching to multipart/form-data.

Proof that the length is actually covered

Sign the same request four times, changing only what the client sends:

issued for 204800 bytes : 78a3d4053da47b2d0174
client sends 3 GB       : be25cac496620f737f36   different -> 403
client sends 204799     : ff0fdc084cc238c93752   different -> 403
client claims text/html : 4fda2306c8f590620bb4   different -> 403

One byte off and the signature changes. That is what "signed" means, and it is
what passing ContentLength to an SDK helper does not give you.

It is stricter than the POST policy, and that is a trade

content-length-range is a range. A signed content-length is an exact value.
You lose the ability to say "anything between 1 byte and 2 MiB".

In a browser that costs you nothing, because file.size is known before you
ask your server for the URL. Ask for a URL for exactly that many bytes. It
matters if you genuinely do not know the size up front, and then POST is your
answer.

What the signed PUT does not give you either way: starts-with conditions,
a policy expiry independent of the URL, and any constraint on a header you did
not sign.

Three things the size limit does not fix

The declared content type is attacker controlled. Signing content-type
pins it to what your server chose, which is good, but your server chose it from
something the client told it. Decide the real type from the first bytes after
the upload lands: 89 50 4E 47 0D 0A 1A 0A is PNG, FF D8 FF is JPEG,
25 50 44 46 is %PDF. Serve user content as an attachment with
X-Content-Type-Options: nosniff regardless, because that is the defence that
holds when the sniffing is wrong.

The object key is not access control. A long random key is not a secret.
Keys end up in logs, in Referer headers, in backups, in anything that has
listed the bucket. Either every read is authorized by your server, or the file
is public and you have not noticed.

The upload happens outside your transaction. The browser uploads, your
database knows nothing. Write a pending row before you issue the URL, flip it
to ready on a callback or an S3 event, and run a job that deletes pending
rows older than some window along with whatever they point at. If the browser
calls that callback, verify with a HEAD against the store rather than
believing the size the client reports.

Disclosure

I work on an open source library that does uploads this way, which is why I
went looking for this and ended up writing the signing code by hand. The
sixty-line presign above is not a sketch: it produces byte-identical URLs to
the implementation we run, which is tested against live S3 and live R2 on every
commit, including a test that the store itself refuses a body that is not the
signed length.

https://filelayer.dev/guides/private-file-uploads

Your video breaks when you serve it from your own server, and 416 is usually the reason

Jorge — Wed, 07 Oct 2026 18:20:03 +0000

If you moved private files off presigned URLs and started serving them through
your own route, you have probably hit this: images are fine, PDFs are mostly
fine, and video is broken. The player loads, the timeline is dead, and
scrubbing does nothing. There is no error in your logs because as far as your
server is concerned every request was a 200.

The cause is almost always Range, and specifically what you do with a range
you cannot serve. I got this wrong, then I read RFC 9110 properly and measured
what a correct implementation actually answers. Here is the table I wish I had
had.

Why the object store was doing more than you thought

When you redirect to a presigned URL, S3 or R2 is answering the request. That
includes range requests, and it is very good at them. The moment you proxy
instead, that becomes your code, including the parts that have nothing to do
with your application.

It is not optional work. A <video> element sends a range request before it
will let the user scrub at all. A PDF reader asks for the last few bytes first,
because the cross reference table lives at the end of the file. Answer those
wrongly and the file looks corrupt rather than forbidden, which is why this
shows up as a player bug and not as a permissions bug.

The part everyone gets wrong

416 Range Not Satisfiable is what you reach for when a range cannot be served
as asked. It is almost always the wrong answer.

RFC 9110 says an invalid range must be ignored. Not refused, ignored: you
answer 200 with the whole representation, as if the header had not been there.
416 is reserved for a range that parsed cleanly and cannot be satisfied by this
particular object, which is a much narrower case than it sounds.

Here is what that means in practice. Twenty six bytes, one per letter of the
alphabet, so a wrong offset reads as the wrong letters instead of as plausible
binary:

Range header	status	why
`bytes=9-4`	200	last position before first position, so the range set is invalid
`bytes=-0`	200	a suffix of zero asks for nothing
`bytes=abc`	200	unparseable
`items=0-4`	200	a unit that is not `bytes`
`bytes=0-4,10-14`	200	multiple ranges, see below
`bytes=99-120`	416	parsed cleanly, past the end of a 26 byte object

Four of the five that look like a 416 are not one. And the one that is carries
something easy to forget:

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */26

That */26 tells the client the actual size, which is the information it needs
to ask a better question. A 416 without it is a dead end.

Multiple ranges deserve their own paragraph

bytes=0-4,10-14 is two questions in one header. You have three options and
only two of them are safe.

You can answer all of them as multipart/byteranges. You can ignore the header
and serve the whole object under a 200. Or you can answer the first one under a
206, which is what a lot of hand written code does because it falls out of the
parser naturally.

That third one is a silent data corruption bug. The client asked two questions.
Nothing in a 206 says only one of them was answered. So it takes your reply,
assumes it covers the first range, and stitches the second range in at an
offset that is now wrong. No error anywhere, and a file that is subtly
different from the one you stored.

Ignoring is the only option that cannot mislead, and it is one line.

The rest of the table, for completeness

The cases that do work, same 26 byte object:

Range header	status	Content-Range	body
none	200		`abcdefghijklmnopqrstuvwxyz`
`bytes=0-`	206	`bytes 0-25/26`	`abcdefghijklmnopqrstuvwxyz`
`bytes=0-4`	206	`bytes 0-4/26`	`abcde`
`bytes=-4`	206	`bytes 22-25/26`	`wxyz`
`bytes=20-999`	206	`bytes 20-25/26`	`uvwxyz`

Two things in there are worth pointing out.

bytes=-4 is a suffix, not a negative offset. It means the last four bytes.
If you parse it as "start at -4" you will either throw or serve from the
beginning, and the PDF reader that sent it will decide your file is damaged.

bytes=20-999 is not an error. A last position past the end of the object is
satisfiable per the spec, and the response covers to the end. Returning 416
here is the second most common mistake after the ones in the first table.

Accept-Ranges goes on every response, including the 200

This is the one I had backwards for a while.

Accept-Ranges: bytes is how a client learns it is allowed to seek. So it has
to be on the plain unranged 200, which is the response the client reads before
it has ever sent a range. Sending it only on 206 responses tells the client
something it already knew, at the only moment it cannot act on it.

A parser that gets the above right

About thirty lines. Returns null for anything that must be ignored, and
null never means error:

type RangeSpec = { start: number; end?: number } | { suffix: number };

function parseRange(raw: string | undefined): RangeSpec | null {
  if (typeof raw !== 'string') return null;
  const m = /^bytes=(.*)$/.exec(raw.trim());
  if (!m) return null;                      // another unit, or not a range

  const specs = m[1].split(',');
  if (specs.length !== 1) return null;      // multiple ranges: ignore, serve whole
  const spec = specs[0].trim();

  const suffix = /^-(\d+)$/.exec(spec);
  if (suffix) {
    const n = Number(suffix[1]);
    if (!Number.isSafeInteger(n) || n === 0) return null;
    return { suffix: n };                   // the LAST n bytes
  }

  const explicit = /^(\d+)-(\d*)$/.exec(spec);
  if (!explicit) return null;
  const start = Number(explicit[1]);
  if (!Number.isSafeInteger(start)) return null;
  if (explicit[2] === '') return { start };

  const end = Number(explicit[2]);
  if (!Number.isSafeInteger(end)) return { start };   // absurd last-pos means "to the end"
  if (end < start) return null;             // invalid, so ignored, NOT a 416
  return { start, end };
}

Then, when you resolve it against the real object size:

// `null` from the parser: no range was asked for, or it must be ignored.
if (!range) return respond(200, whole, { 'accept-ranges': 'bytes' });

const start = 'suffix' in range
  ? Math.max(0, size - range.suffix)
  : range.start;

// The only 416: it parsed, and this object cannot satisfy it.
if (start >= size) {
  return respond(416, null, {
    'content-range': `bytes */${size}`,
    'accept-ranges': 'bytes',
  });
}

const end = 'suffix' in range ? size - 1 : Math.min(range.end ?? size - 1, size - 1);

return respond(206, slice(start, end), {
  'content-range': `bytes ${start}-${end}/${size}`,
  'accept-ranges': 'bytes',
});

One thing to be careful about in the 206 path: derive the status from whether
you are sending a partial body, do not let the caller pass it in. A partial
body sent under a 200 is undetectable by every HTTP client on earth. It stores,
caches, hashes and hands on a truncated file without a single error anywhere.
The status code is the only thing that makes it a range.

How to check your own route in five minutes

Put a file of known length behind your route and run these. You do not need a
player to find out whether seeking will work:

curl -s -o /dev/null -D - -H 'Range: bytes=0-4'     "$URL"   # expect 206
curl -s -o /dev/null -D - -H 'Range: bytes=-4'      "$URL"   # expect 206, last 4 bytes
curl -s -o /dev/null -D - -H 'Range: bytes=9-4'     "$URL"   # expect 200, whole file
curl -s -o /dev/null -D - -H 'Range: bytes=0-4,9-12' "$URL"  # expect 200, whole file
curl -s -o /dev/null -D - -H 'Range: bytes=999999-' "$URL"   # expect 416 + Content-Range
curl -s -o /dev/null -D -                           "$URL"   # expect Accept-Ranges: bytes

If the third or fourth one comes back 416, that is the bug your video player is
reacting to. If the last one has no Accept-Ranges, the player will not even
try to seek.

Disclosure

I work on an open source library that serves private files, so I wrote this
parser and then wrote the tests that pin every row of those tables. The tables
above are the output of a script, not my recollection. The script is in the
repo, so you can point it at your own implementation and see what yours does.

https://filelayer.dev/guides/serving-private-files

Parsing Bank Statement PDFs: 5 Tools Compared for Developers (2026)

Jorge — Tue, 21 Apr 2026 19:09:05 +0000

You need to extract transaction data from bank statement PDFs programmatically. Maybe you are building a personal finance app, an accounting integration, or a data pipeline that reconciles bank data against internal records. Whatever the reason, you have already discovered the fundamental problem: PDF is a display format, not a data format.

Tables in PDFs are visual constructs. There are no <table>, <tr>, or <td> elements — just text fragments positioned at specific x/y coordinates on a page. What looks like a row to a human is, to a parser, a collection of unrelated text objects that happen to share a similar y-coordinate. Bank statements make this worse: merged header cells, variable column widths across institutions, running balances that wrap across page boundaries, debit/credit columns that sometimes merge into a single signed-amount column, and — still common in 2026 — scanned paper originals that need OCR before any text extraction is possible.

I benchmarked five tools against 50 real bank statements from 17 institutions. Here is what works.

1. Tabula / Camelot — Open-Source, Self-Hosted

Accuracy: 81% | Price: Free | API: Local library

Tabula (Java) and Camelot (Python) are the go-to open-source options for PDF table extraction. Both use two parsing strategies:

Lattice mode — detects ruled lines in the PDF and uses them as cell boundaries. Works well when the bank statement has visible grid lines.
Stream mode — infers column boundaries from text alignment when no ruled lines exist. More fragile, but handles statements with no visible table borders.

Camelot is generally easier to integrate into Python pipelines:

import camelot

# Lattice mode — use when the PDF has visible table lines
tables = camelot.read_pdf(
    "statement.pdf",
    pages="all",
    flavor="lattice"
)

for table in tables:
    df = table.df
    # First rows are usually headers — inspect and clean
    print(df.head())
    df.to_csv(f"table_{table.order}.csv", index=False)

import camelot

# Stream mode — use when the table has no visible borders
tables = camelot.read_pdf(
    "statement.pdf",
    pages="all",
    flavor="stream",
    edge_tol=50,       # tolerance for edge detection
    row_tol=5          # tolerance for row grouping
)

# Check parsing accuracy score (0-100)
for table in tables:
    print(f"Table {table.order}: accuracy {table.parsing_report['accuracy']:.1f}%")

Tabula-py wraps the Java Tabula library:

import tabula

# Extract all tables from all pages
dfs = tabula.read_pdf(
    "statement.pdf",
    pages="all",
    multiple_tables=True,
    lattice=True        # switch to stream=True for borderless tables
)

for i, df in enumerate(dfs):
    print(f"Table {i}: {len(df)} rows")
    df.to_excel(f"table_{i}.xlsx", index=False)

The hard truth: Both tools scored 81% on bank statements. The failures cluster around multi-page tables (headers not repeated, so page 2+ tables lack column context), merged cells in statement headers, and any layout that mixes lattice and stream regions. Neither supports OCR — scanned PDFs return empty results.

Best for: Pipelines where you control the PDF source, it is always digitally generated, and you can write bank-specific post-processing logic to handle edge cases.

2. pdftoxlsx — Web-Based Bank Statement Specialist

Accuracy: 99.1% | Price: Free tier | API: Not yet (web upload/download)

Disclosure: I built this tool.

pdftoxlsx.com is purpose-built for bank statement conversion. The parsing engine uses bank-specific layout recognition — it identifies the institution, selects the appropriate parsing template, and handles the quirks of that bank's PDF format (column structure, date formats, multi-currency handling, page-break continuation).

In the benchmark, it hit 99.1% field-level accuracy across 50 statements from 17 banks. It handles scanned PDFs via built-in OCR, correctly parses multi-page continuation tables, and resolves the debit/credit column ambiguity that trips up general-purpose tools.

The limitation for developers: There is no public API yet. The current workflow is web upload and Excel download. For automated pipelines, this is a friction point. If you need a one-off conversion or you are doing exploratory analysis on bank data, the web interface is fast and the output is clean. For production pipelines processing hundreds of statements, you need something with an API.

Best for: Getting bank statement data into a structured format quickly when you need accuracy over automation. Useful for validating your own parser's output against a high-accuracy reference.

3. Nanonets — ML-Powered, API-First

Accuracy: 88.7% | Price: From $499/mo | API: REST

Nanonets uses machine learning models trained on document layouts. You can use their pre-trained bank statement model or fine-tune with your own labeled data. The REST API is well-documented and supports webhooks for async processing.

The 88.7% accuracy out of the box is solid — and the key advantage is that accuracy improves as you feed corrections back into the model. For teams processing statements from a consistent set of banks, the model converges quickly.

Technical details: Nanonets handles OCR internally (proprietary engine, not Tesseract), supports coordinate-based extraction for non-table regions (e.g., pulling the account number from the statement header), and returns structured JSON with confidence scores per field.

POST https://app.nanonets.com/api/v2/OCR/Model/{model_id}/LabelFile/
Content-Type: multipart/form-data

Response:
{
  "result": [{
    "prediction": [{
      "label": "transaction_date",
      "ocr_text": "04/15/2026",
      "confidence": 0.97,
      "xmin": 45, "ymin": 312, "xmax": 142, "ymax": 328
    }]
  }]
}

Best for: Enterprise pipelines that need custom model training, process high volumes, and can justify the price point. The feedback loop for accuracy improvement is the real differentiator.

4. DocParser — Cloud + API with Custom Rules

Accuracy: 85.3% | Price: From $39/mo | API: REST + Webhooks

DocParser sits between the open-source DIY approach and the ML-powered enterprise approach. You define parsing rules through a visual editor — specifying table regions, column mappings, and data types — and then the API processes documents against those rules.

It scored 85.3% on bank statements with default settings. The accuracy improves once you create bank-specific parsing templates, but the setup cost is non-trivial: each bank layout needs its own template, and template maintenance becomes a task when banks update their statement formats.

The API supports cloud storage integrations (S3, Google Drive, Dropbox), webhook notifications, and batch processing. The JSON output is well-structured and consistent.

Best for: Multi-document-type pipelines where you process invoices, receipts, purchase orders, and bank statements. One platform, multiple document templates. The rule-based approach is transparent and debuggable, which matters when you need to explain extraction logic to auditors.

5. PDFTables — API-Focused, Pay Per Page

Accuracy: 83.6% | Price: Pay per page (from $0.04/page) | API: REST

PDFTables offers the simplest API integration of the five tools. Upload a PDF, get back CSV/XLSX/XML. No configuration, no templates, no training.

import requests

response = requests.post(
    "https://pdftables.com/api?key=YOUR_API_KEY&format=csv",
    files={"file": open("statement.pdf", "rb")}
)

with open("output.csv", "wb") as f:
    f.write(response.content)

It scored 83.6% on bank statements. The pay-per-page model is attractive for variable workloads — no monthly commitment, no wasted capacity. The API is fast (sub-second for most single-page documents) and handles OCR for scanned PDFs.

Best for: Batch processing with minimal setup. If you need a quick, low-commitment API to drop into an existing pipeline and can handle some post-processing cleanup, PDFTables is the path of least resistance.

Technical Notes

A few things I learned running the benchmark that are worth knowing:

OCR engine matters. Tools using Tesseract 5.x perform noticeably better than Tesseract 4.x on bank statements, particularly on compressed or low-resolution scans. If you are rolling your own OCR pipeline, upgrade. Commercial OCR engines (ABBYY, Adobe's) outperform Tesseract on degraded scans but the gap has narrowed significantly.

Lattice vs. stream is not either/or. Many bank statements use ruled lines for the transaction table but have borderless summary sections. Tools that auto-detect and switch modes mid-document (or let you specify regions) perform better than those locked into one strategy.

Coordinate-based extraction complements table parsing. Account numbers, statement dates, opening balances, and bank identifiers live outside the main table. Extracting these via coordinate ranges (or regex on the full-page text) and merging with the table data produces a more complete output.

Multi-page tables are the hardest problem. A 3-page statement where the table starts mid-page-1 and ends mid-page-3, with no repeated headers on pages 2-3, breaks most general-purpose parsers. This is where bank-specific logic (knowing the table structure in advance) wins.

The Verdict

Need	Recommendation
Quick, accurate bank statement conversion	pdftoxlsx (99.1%, no API yet)
Free, self-hosted pipeline for digital PDFs	Tabula/Camelot (81%, no OCR)
Enterprise pipeline with model training	Nanonets (88.7%, $499/mo)
Multi-document-type processing	DocParser (85.3%, $39/mo)
Simple API, pay-per-use	PDFTables (83.6%, per-page pricing)

If you need a quick solution for bank statements specifically, pdftoxlsx wins on accuracy. If you are building an automated pipeline, the choice is between Tabula (free, self-hosted, digital-only) and Nanonets (enterprise, ML-powered, handles everything) — depending on budget and volume.

For most developers building a fintech integration, the practical path in 2026 is: start with Camelot for prototyping, validate your output against pdftoxlsx for accuracy benchmarking, and move to Nanonets or DocParser when you need production-grade automation at scale.

Benchmark methodology and full results: pdftoxlsx.com/blog/benchmark-2026