parallax/jsPDF · error · Error

Image dimensions exceed 512MB, which is too large.

Error message

Image dimensions exceed 512MB, which is too large.

What it means

Thrown in decodeAndBlitFrameBGRA when frame.width * frame.height exceeds 512*1024*1024 pixels. It prevents allocating a Uint8Array of index data that would exhaust memory. This is a defensive ceiling on a single GIF frame's pixel count before the LZW decode and blit.

Source

Thrown at src/libs/omggif.js:615

    return frames.length;
  };

  this.loopCount = function() {
    return loop_count;
  };

  this.frameInfo = function(frame_num) {
    if (frame_num < 0 || frame_num >= frames.length)
      throw new Error("Frame index out of range.");
    return frames[frame_num];
  };

  this.decodeAndBlitFrameBGRA = function(frame_num, pixels) {
    var frame = this.frameInfo(frame_num);
    var num_pixels = frame.width * frame.height;

    if (num_pixels > 512 * 1024 * 1024) {
      throw new Error("Image dimensions exceed 512MB, which is too large.");
    }

    var index_stream = new Uint8Array(num_pixels); // At most 8-bit indices.
    GifReaderLZWOutputIndexStream(
      buf,
      frame.data_offset,
      index_stream,
      num_pixels
    );
    var palette_offset = frame.palette_offset;

    // NOTE(deanm): It seems to be much faster to compare index to 256 than
    // to === null.  Not sure why, but CompareStub_EQ_STRICT shows up high in
    // the profile, not sure if it's related to using a Uint8Array.
    var trans = frame.transparent_index;
    if (trans === null) trans = 256;

    // We are possibly just blitting to a portion of the entire frame.

View on GitHub (pinned to a3930ce03a)

Solutions

1. Pre-check reader.width/height and the frame's width/height (via frameInfo) and reject or downscale before decoding.
2. Sanitize/re-encode oversized GIFs with an image tool before passing to jsPDF.
3. Validate uploaded GIFs against a max pixel budget at the application boundary.

Example fix

// before
reader.decodeAndBlitFrameBGRA(0, pixels);

// after
var info = reader.frameInfo(0);
var px = info.width * info.height;
if (px > 256 * 1024 * 1024) {
  throw new Error('GIF frame too large to embed safely: ' + px + ' pixels');
}
reader.decodeAndBlitFrameBGRA(0, pixels);

var MAX_PIXELS = 256 * 1024 * 1024; // stay under jsPDF's 512M ceiling
var info = reader.frameInfo(0);
if (info.width * info.height > MAX_PIXELS) {
  throw new Error('Frame too large: ' + info.width + 'x' + info.height);
}
reader.decodeAndBlitFrameBGRA(0, pixels);

function frameWithinBudget(reader, idx, maxPixels) {
  var i = reader.frameInfo(idx);
  return (i.width * i.height) <= maxPixels;
}

try {
  reader.decodeAndBlitFrameBGRA(0, pixels);
} catch (e) {
  if (/exceed 512MB/.test(e.message)) {
    return downscaleOrReject(e);
  }
  throw e;
}

When it happens

Trigger: Decoding a GIF frame whose stored width*height product is enormous (e.g. a crafted 'decompression bomb' GIF with a huge logical frame, or a legitimately very large image). The check fires before allocation so no huge buffer is created.

Common situations: Processing untrusted user-uploaded GIFs that may be maliciously oversized; embedding a high-resolution GIF into a PDF; a corrupt dimension field inflating the computed pixel count.

Related errors

• Frame index out of range.
• Width/Height invalid.
• Invalid code/color length, must be power of 2 and 2 .. 256.
• Background index out of range.
• Background index explicitly passed as 0.

AI-assisted analysis of parallax/jsPDF@a3930ce03a (2026-08-13). Data as JSON: /api/errors/b176f2a0ca387290. Report an issue: GitHub.