gchq/CyberChef · error · OperationError

Error resizing image. (${err})

Error message

Error resizing image. (${err})

What it means

Thrown by the Resize Image operation when an exception occurs during the Jimp resize/scaleToFit or getBuffer calls inside run(). Any error raised by Jimp (bad dimensions, unsupported algorithm, encoding failure) is caught and re-wrapped as an OperationError with the original error message embedded. GIFs are re-encoded as PNG, which can itself fail.

Source

Thrown at src/core/operations/ResizeImage.mjs:130

                    mode: resizeMap[resizeAlg],
                });
            } else {
                image.resize({
                    w: width,
                    h: height,
                    mode: resizeMap[resizeAlg],
                });
            }

            let imageBuffer;
            if (image.mime === "image/gif") {
                imageBuffer = await image.getBuffer(JimpMime.png);
            } else {
                imageBuffer = await image.getBuffer(image.mime);
            }
            return imageBuffer.buffer;
        } catch (err) {
            throw new OperationError(`Error resizing image. (${err})`);
        }
    }

    /**
     * Displays the resized image using HTML for web apps
     * @param {ArrayBuffer} data
     * @returns {html}
     */
    present(data) {
        if (!data.byteLength) return "";
        const dataArray = new Uint8Array(data);

        const type = isImage(dataArray);
        if (!type) {
            throw new OperationError("Invalid file type.");
        }

        return `<img src="data:${type};base64,${toBase64(dataArray)}">`;

View on GitHub (pinned to 4290ea7539)

Solutions

1. Check the wrapped 'err' string — it carries the underlying Jimp failure and pinpoints resize vs. getBuffer.
2. Ensure Width/Height are positive numbers; for 'Percent' unit use values 1-100 to avoid fractional/negative pixel dimensions.
3. If the input is a GIF, convert it to PNG before resizing, since the operation re-encodes GIFs as PNG and animated GIFs can fail.
4. Reduce the image size or run outside the worker if memory limits are the cause.

Example fix

// before
ResizeImage.run(buffer, [-50, -50, "Percent", false, "Bilinear"])
// after
ResizeImage.run(buffer, [50, 50, "Percent", false, "Bilinear"])

// Validate dimensions before calling run()
const [w, h, unit] = args;
if (unit === "Percent" && (w <= 0 || h <= 0 || w > 100 || h > 100)) {
  throw new Error("Percent width/height must be between 1 and 100");
}
if (unit === "Pixels" && (w < 1 || h < 1)) {
  throw new Error("Pixel width/height must be >= 1");
}
const VALID_ALGS = ["Nearest Neighbour", "Bilinear", "Bicubic", "Hermite", "Bezier"];
if (!VALID_ALGS.includes(args[4])) {
  throw new Error("Unknown resize algorithm: " + args[4]);
}

try {
  const out = await resizeImage.run(buf, args);
} catch (e) {
  if (e instanceof OperationError && /Error resizing image/.test(e.message)) {
    // e.message embeds the underlying Jimp error
  }
}

When it happens

Trigger: Calling ResizeImage.run() with a 'Percent' unit that produces NaN/Infinity dimensions (e.g. zero or negative percent), passing an unmapped resize algorithm string so resizeMap[resizeAlg] is undefined, or getBuffer() failing on a corrupted or unsupported image. Large images that exhaust worker memory also surface here.

Common situations: Passing width/height of 0 with Percent unit; supplying an image Jimp can decode but not re-encode (e.g. exotic GIF/animated frames); running against very large images in a memory-constrained web worker; a Jimp version change where ResizeStrategy enum names drift.

Related errors

• Error containing image. (${err})
• Error covering image. (${err})
• Invalid file type.
• Error loading image. (${err})
• Error loading image. (${err})

AI-assisted analysis of gchq/CyberChef@4290ea7539 (2026-08-13). Data as JSON: /api/errors/366c6ae3b728e97b. Report an issue: GitHub.