Resize Percentage Tops Out at 100 on One Platform, and Doubles on Four Others

Resize Image looks like the simplest endpoint in PDF4me's image toolkit. Give it a percentage, get a smaller or bigger file back. That assumption holds on four of the five surfaces this feature ships through. It does not hold on the fifth, and the gap only shows up once a workflow tries to enlarge an image instead of shrink one.

What "resize by percentage" is supposed to mean

Across Resize Image on the REST API, the endpoint accepts a resize type and, for percentage mode, a single numeric value applied to both dimensions of the source image. The plain reading of "percentage" is symmetrical: a value under 100 shrinks the image, a value over 100 enlarges it, 100 leaves it unchanged. That is exactly how Power Automate's Resize Image action documents it. The parameter table's own worked example spells out both directions at once: 50 for half size, 200 for double. Zapier's Resize Image step carries the identical worked example, 50 for half size, 200 for double, word for word. n8n's Resize Image node states the same behavior in its own language: below 100 reduces the image, above 100 enlarges it. Its FAQ section goes a step further and directly confirms that pushing the value past 100 increases the output's pixel dimensions, while also noting the honest limit that comes with any upscale, that resizing cannot recover detail the original capture never had. Three separate integration platforms, three separate documentation pages, one consistent behavior: percentage mode is a two-way dial.

The platform where it is not

Make's Resize Image module documents a hard ceiling. Its Important Facts section states the percentage field caps at 100. Its Practical Tips section repeats the same constraint in different words. Its FAQ section addresses the upscale question directly and answers it the same way a third time: scaling up is not supported, because the field caps at 100. That is not a rounding footnote or a minor phrasing difference from the other three platforms. It is the opposite behavior for the same field, on the same underlying feature, described three separate times on the same page, which rules out a documentation typo and leaves an actual product constraint on that one integration surface.

Put the four pages next to each other and the split is clean. Power Automate: 50 to 200 range, worked example included. Zapier: 50 to 200 range, identical worked example. n8n: below 100 shrinks, above 100 enlarges, FAQ-confirmed. Make: capped at 100, no upscale path through this field, stated three times on one page. A workflow builder who tests the enlarge case on Power Automate, Zapier, or n8n and then rebuilds the same flow on Make will hit a silent ceiling that none of those other three platforms have.

The actual REST request, verified against the live sample

The REST payload's field names are worth pinning down exactly, since the docs page's own JSON example and the official Python sample in the pdf4me-api-samples repo agree on everything except one field the marketing payload leaves out:

import requests, base64

url = "https://api.pdf4me.com/api/v2/ResizeImage?schemaVal=Percentange"

with open("sample.jpg", "rb") as f:
    image_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docName": "sample.jpg",
    "docContent": image_base64,
    "ImageResizeType": "Percentage",   # or "Specific"
    "ResizePercentage": "50.0",         # decimal as string
    "Width": 800,                       # used when ImageResizeType is Specific
    "Height": 600,
    "MaintainAspectRatio": True,
    "isAsync": True                     # not in the docs page's JSON example, present in the official sample
}

headers = {"Authorization": "Basic YOUR_API_KEY", "Content-Type": "application/json"}
response = requests.post(url, json=payload, headers=headers, timeout=300)

# 200: resized image returned directly in the response body
# 202: async job accepted, poll the Location header URL until it returns 200

Two things worth flagging in that payload. First, the query string's own default value is schemaVal=Percentange, not Percentage, a literal misspelling that appears verbatim across the docs page, the C# and Python samples, and the Salesforce class in the sample repo. Copy it exactly as published rather than correcting the spelling. Second, isAsync does not appear in the docs page's own "Payload" JSON example, only in the actual Python sample script. Anyone copying the docs page's example verbatim will get a payload that works but silently defaults async handling rather than declaring it, which matters if a caller wants to rely on the 202-plus-polling path documented in the sample script's own status-code handling. The Resize Image entry in the interactive API Tester is the fastest way to confirm the exact parameter casing a specific account's endpoint expects before writing code against it.

Why this matters more than a single mismatched field

Document automation pipelines get built once and reused for months. A logistics team pulling label images off a scanner, an e-commerce operator normalizing product photos before they hit a marketplace feed, a finance team standardizing scanned receipts before an AI parser reads them, all of these are exactly the kind of repeatable image step this endpoint exists for. If the pipeline was prototyped on Zapier or Power Automate with a 150 or 200 percent value to upscale a low-resolution source, and the same logic later gets ported to Make because that is the automation tool the rest of the org standardized on, the enlarge step does not error loudly. It just does not enlarge. The field accepts the value, caps it at 100 internally per Make's own documentation, and the output comes back at original size. That is a much harder failure to catch in a screenshot review than an outright error message would be, because nothing in the run log necessarily flags it as a problem. It looks like the step ran successfully. It just did not do what the same configuration would have done on a different platform.

This is also a case where checking the REST API page alone would not have caught the discrepancy. The REST documentation describes percentage mode generically, the same way Power Automate, Zapier, and n8n do, without calling out any upper limit. The cap lives specifically in how Make's module wraps that underlying call, not in the API contract itself. Anyone building on Make needs Make's own page open, not just the REST reference, before assuming the field behaves the way it does everywhere else PDF4me exposes it.

One more asymmetry: Power Automate's extra resize mode

Power Automate's Resize Image action documents a third resize type beyond percentage and fixed pixel dimensions: Max Dimensions, which takes separate MaxWidth and MaxHeight fields and scales the image down to fit inside that bounding box while preserving aspect ratio. Nothing in the REST API page, the Make module page, the Zapier step page, or the n8n node page describes an equivalent third mode. That does not mean the underlying capability is impossible to replicate elsewhere, only that it is not documented as a first-class option outside Power Automate's action today. A team standardizing a multi-platform image pipeline and relying on Max Dimensions logic inside Power Automate should not assume the same named mode exists if that workflow gets rebuilt on Make, Zapier, or n8n. It would need to be approximated with the fixed-dimension or percentage modes those platforms do document, calculated manually against the source image's known size.

What to actually check before building on this endpoint

None of this is a case for avoiding Resize Image. It is a case for reading the specific platform's own page before assuming percentage mode behaves identically everywhere PDF4me exposes it, because on this endpoint, for this one direction of the operation, it does not. Four platforms agree, one does not, and the disagreement is buried in a parameter table and an FAQ section rather than surfaced anywhere a workflow builder would see it by default. For any pipeline that needs to enlarge an image and not just shrink one, confirming which platform is running the resize step is worth the thirty seconds it takes, before a value like 150 or 200 gets typed in and quietly does nothing.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com