ScaleTo

ScaleTo does not resize anything. Say that twice, because half the people who land on this page expect a resize node and get confused when a "Scale" node doesn't touch pixels. It's arithmetic: multiply a width and a height by a scale factor, round to integers, hand you back both the new pair and the scale you fed in.

That sounds like nothing, and it's genuinely useful the moment you build a two-pass workflow. Hi-res fix means a base pass at native resolution, then a latent upscale by some factor, then a second sampling pass - and the "some factor" is a number you need in two or three places at once: the upscale node, the empty latent for the second pass, and maybe the saver. Doing that multiplication by hand is how you end up with a second pass that's 1536 wide when the sampler thinks it's 1520.

Inputs and outputs

Three inputs, all required: width (INT, default 1024, min 0), height (INT, default 1024, min 0) and scale (FLOAT, default 1, step 0.01, min 0). Three outputs: target_width, target_height, and scale - the input scale, returned unchanged so you can pass it straight through to whatever actually performs the resize. Wire scale into a latent upscale node's scale input and target_width/target_height into your latent or image dimensions, and the two can't disagree.

The mechanism is worth a line because it explains the rounding. The node converts the scale to a Fraction of its decimal text - str(1.5) → 3/2 - and multiplies exactly, rather than doing float math and hoping. Exact halfway values round to the nearest even integer, which is the standard banker's-rounding rule and the same thing Python's round() does. So 0.5 of 1013 goes to 1014, not 1013. The practical effect: a scale typed as 1.05 behaves predictably instead of drifting by one pixel depending on the width.

It also shows the resulting dimensions on the node face, (1024x1536), so you can read the answer off the canvas without opening anything.

The trap it does not save you from

ScaleTo rounds to the nearest integer. It does not round to a multiple of 8 or 64, and that's the thing that actually breaks second passes. Latent-based pipelines need dimensions divisible by 8; the newer architectures want 64 (Flux, and the 2026 crop of models, will happily produce garbage or complain outright at arbitrary sizes). So 1024 × 1.2 = 1228 - a perfectly correct integer that no latent node wants. Keep your scale factors on values that land on multiples of 64 (1.5× of 1024 is 1536, fine; 1.25× of 1024 is 1280, fine), or round the result yourself downstream.

Two smaller things: scale accepts 0, which gives you a target of 0×0 and a very confused sampler, and the node raises on negative or non-finite scales. Both are guardrails, not features.

When to use it, and when not to

Use it in two-pass graphs where you're composing the resize from separate nodes - a primitive for the base resolution, ScaleTo for the math, a latent upscale node for the actual work. If you're using a single "upscale everything" node that takes a multiplier directly, you don't need ScaleTo; you already have the one number.

Don't reach for it as a way to change the aspect ratio. It's a uniform multiplier on both axes, so what you put in comes back proportionally. And it won't fix a bad base resolution for you - the KB's upscaling guidance is that anything above native resolution wants a proper two-pass setup, and this node is just the calculator inside one.

Install

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/lany42/comfyui-lany-nodes.git
# restart ComfyUI

Manager: search comfyui-lany-nodes ("ComfyUI Lany Nodes"). Nothing to download - the pack's only runtime dependencies are numpy and Pillow, and this node doesn't even use those. It does require Python 3.13+ and ComfyUI's V3 node API, so a current build; on an old one the pack registers nothing and you'll find no ScaleTo in the Lany Nodes category.