Ask five developers what "resize an image" means and you will get five different answers. One means shrinking a 4000px camera photo down to a 200px thumbnail. Another means scaling every image in a batch to 80% so a page loads faster. A third means forcing every upload into an exact 600x600 box regardless of what came in. These are not the same operation, and the way most image libraries handle them (one function, a dozen optional flags, an aspect ratio bug waiting to happen) is exactly why resize logic tends to accumulate as one of those "someone wrote this three years ago and nobody wants to touch it" corners of a codebase.
PDF4me's Resize Image endpoint treats the two real-world resize methods as two real, distinct parameters instead of one overloaded function, and that distinction is worth understanding before you wire it into anything.
Percentage and pixels are different problems, not two flags on the same one
Resize by percentage answers "make this smaller, proportionally, without me having to know its exact dimensions." A batch of product photos that arrive at wildly different resolutions can all get scaled down by 50% and come out proportionally consistent, whatever their starting size.
Resize by exact pixel dimensions answers a completely different question: "I need this to be 600 by 400, full stop." That is the shape of the problem when a destination has a hard requirement: a thumbnail grid that expects uniform tiles, a CMS field with a fixed image slot, a print template with a defined canvas. Asking a single "resize" call to guess which one you meant is how you end up with distorted product photos or under-sized thumbnails nobody caught in code review.
PDF4me's endpoint exposes both as first-class options via the ImageResizeType field, which takes either Percentage or Specific. You pick the method that matches the actual problem instead of coercing one flag to do both jobs.
What the request actually looks like
The REST call is a POST to /api/v2/ResizeImage, and the request body is unremarkable in the way a well-designed document API's request body should be. Here is the field-by-field shape, verified against the official pdf4me-api-samples Python sample rather than just the marketing-page example:
import os
import base64
import requests
import time
def resize_image():
api_key = "get the API key from https://dev.pdf4me.com/dashboard/#/api-keys"
image_file_path = "sample.jpg"
output_path = "Resize_image_output.jpg"
base_url = "https://api.pdf4me.com"
url = f"{base_url}/api/v2/ResizeImage"
with open(image_file_path, "rb") as f:
image_content = f.read()
image_base64 = base64.b64encode(image_content).decode('utf-8')
payload = {
"docName": os.path.basename(image_file_path),
"docContent": image_base64,
"ImageResizeType": "Percentage", # or "Specific"
"ResizePercentage": "50.0",
"Width": 800, # used when ImageResizeType is "Specific"
"Height": 600, # used when ImageResizeType is "Specific"
"MaintainAspectRatio": True,
"isAsync": True
}
headers = {
"Authorization": f"Basic {api_key}",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers, timeout=300)
if response.status_code == 200:
# Synchronous completion
with open(output_path, "wb") as f:
f.write(response.content)
elif response.status_code == 202:
# Asynchronous processing: poll the Location header until done
location_url = response.headers.get('Location')
for attempt in range(20):
time.sleep(10)
poll = requests.get(location_url, headers=headers)
if poll.status_code == 200:
with open(output_path, 'wb') as out_file:
out_file.write(poll.content)
break
elif poll.status_code != 202:
print(f"Error: {poll.status_code} - {poll.text}")
break
A few things worth calling out that are easy to miss from the docs page alone: ImageResizeType takes exactly two values, Percentage or Specific, and both Width/Height and ResizePercentage are sent in every request regardless of which mode you use, the endpoint just ignores whichever pair doesn't apply to the selected type. The isAsync flag is real and documented in the official sample even though the docs page's own JSON example doesn't show it: set it to true and a large or slow-processing image returns a 202 with a Location header to poll instead of holding the connection open, the same async pattern used across PDF4me's other endpoints. Authentication uses Authorization: Basic {api_key}, and the response for a synchronous 200 is the resized image itself as binary content, not a JSON wrapper.
The aspect ratio setting nobody reads until something looks wrong
Here is the setting that actually decides whether your resized image looks correct or looks broken: MaintainAspectRatio. Leave it true and a percentage or pixel resize scales width and height together, so a landscape photo stays a landscape photo, just smaller. Set it false, or set a target width and height that do not match the source's proportions, and you get exactly what you asked for: an image forced into a box, stretched or squashed to fit.
There is a real use case for both. A thumbnail grid that needs every tile to be a literal square wants MaintainAspectRatio: false and a fixed pixel target, because uniformity is the point. A hero image being scaled down for a slower connection wants it locked true, because nobody wants a portrait photo of a person rendered as a slightly wider person. The mistake is not knowing which one your integration is set to, and finding out only when a customer screenshots a warped logo.
Resizing without touching the REST payload yourself
Not every team wants to own a resize function, and PDF4me's no-code integrations exist for exactly that reason. In Power Automate, the Resize Image action takes the same percentage-or-dimensions choice and the same aspect ratio control, dropped into a flow alongside whatever triggers it: a new file landing in SharePoint, an email attachment, a form submission, with batch processing built into the action itself.
Zapier ships the same capability under the name "Smart Scaler," and if you are already routing images through a Zap, inserting resize as a middle step means you never write image-processing code at all.
n8n's node is aimed squarely at the two jobs developers actually reach for it for: generating thumbnails on the fly and normalizing a pile of inconsistent uploads into one predictable size, both by percentage or exact pixels, with aspect ratio preserved by default.
Make covers percentage-based scaling for jobs like thumbnail generation and web optimization, with one caveat worth knowing before you build around it: there is no dedicated batch-resize mode in the module itself. Resizing more than one file means wrapping the module in a Make Iterator and letting it run the same percentage setting once per image. If your scenario already resizes a folder of files one at a time, this is not a limitation you will notice. If you are picturing a single-step bulk operation, plan for the Iterator up front rather than after your first test run comes up short.
Test the exact request before you build a pipeline around it
Before wiring resize into a workflow that will run unattended, confirm the exact request and response shape against a real image using PDF4me's feature-specific Resize Image API Tester (or the general API Tester for any other endpoint), which sends live requests from the browser and returns the actual response, no code required. This matters more for resize than it might for a simpler endpoint: aspect ratio behavior, the decimal format for percentage values, and how a non-square pixel target actually renders are all things that are faster to see once, live, than to debug after the fact in a batch job.
Where this actually gets used
The pattern that comes up most is normalization: user uploads arrive in every resolution imaginable, and a fixed downstream requirement (a thumbnail grid, a storage budget, a CMS image slot) needs them all brought to one size before anything else touches them. The second most common pattern is bandwidth: serving a smaller percentage-scaled version of a large photo to a page that does not need full resolution. A third, less obvious pattern is compliance with a third-party spec: marketplaces, print vendors, and ad networks routinely publish exact pixel requirements for submitted images, and rejecting a file for being the wrong size is a worse customer experience than resizing it automatically before it ever gets uploaded.
None of these needs a dedicated image-processing service, a native image library your team now has to patch for security updates, or a homegrown wrapper around one. It is one endpoint, or one no-code action, doing one job correctly, and because it sits on the same PDF4me surface as the rest of the image and document toolset, a resize step chains naturally into a larger pipeline without switching services or re-authenticating partway through.
Getting started
If you have not connected to the PDF4me API before, the Connect to PDF4me API guide covers authentication, API keys, and response codes, and is the fastest path to your first successful call, resize or otherwise.
Website: pdf4me.com
Documentation: docs.pdf4me.com
Top comments (0)