If transparent corners become white, inspect the downloaded GIF before changing every source image. The current ToolboxHub Animated GIF Maker deliberately paints each frame onto an opaque white canvas, so this workflow cannot preserve those transparent pixels even when the input files are transparent PNGs.
Separate a white viewer background from opaque white pixels
A preview shown on a white webpage is not enough to prove that transparency was removed. Download the generated file and view it over a dark or checkerboard background; if the corners stay white instead of revealing that background, the exported pixels are opaque.
This distinction matters because two different symptoms can look identical on the tool page. A transparent corner may merely reveal the page's white surface, or the encoder input may already contain a white matte. Checking the actual download on a contrasting background separates those cases without guessing.
The current implementation provides a stronger source-level clue. For every frame, it creates a canvas at the first image's width and height, fills the whole canvas with #fff, and then draws the image over it. The canvas—not the original file—is handed to the GIF encoder. That behavior was verified from the current component source; no browser GIF was generated during this article task.
This is a limitation of this particular workflow, not evidence that every GIF-producing application must flatten transparency to white. If transparency is a delivery requirement, use an animation editor or encoder whose exported transparency you can verify rather than trying different settings on a tool that has no transparency control.
Reproduce the result with two controlled PNG frames
Use a tiny, non-sensitive sample before committing a long sequence. The worked example below has explicit inputs and a source-derived expected result, so another person can repeat it in their own browser.
Prepare two 64 by 64 PNG files. Give each one a small colored shape in the center and leave all four corners transparent. Name them frame-a.png and frame-b.png, and confirm in an image editor that both files really have an alpha channel rather than a white background.
Open the online GIF maker and add frame-a.png first, then frame-b.png. Keep the shared frame delay at 300 milliseconds and the loop setting at Forever. The Generate button should become available only after both images have finished loading.
The expected animation.gif is 64 by 64 pixels because the first image determines the output dimensions. Based on the inspected drawing code, all four formerly transparent corners are expected to be opaque white in both frames. This expected result is an illustration derived from the current source, not a claim that the GIF was generated during this review.
Download animation.gif, open it over a dark background, and inspect at least one corner while each colored shape is visible. The verification passes only if you can state what the file actually contains: in this tool's current output, the dark background should not show through the corners. Keep the two PNG inputs and the downloaded GIF together so a reviewer can repeat the comparison.
If your result differs, first confirm that you downloaded the newly generated file rather than an older copy with the same name. Record the browser, the two input dimensions, the input order, and the exported dimensions before drawing a conclusion about a changed implementation.
Decide whether a white matte is acceptable before adding more frames
Opaque white may be perfectly usable for a document, slide, or webpage that also has a white background. If that is the approved delivery requirement, make the choice explicit and prepare all source frames against a consistent white matte so edges can be reviewed before animation.
If the GIF must sit on dark and light surfaces, or its surrounding color can change, white flattening is a blocking limitation. Stop after the two-frame test and switch to a transparency-preserving workflow. Renaming animation.gif to another extension would not convert its pixels, and putting a transparent PNG first would not help because the component fills the canvas before drawing every frame.
The related image format converter handles individual still images and can help create controlled format samples, but it is not an animated-GIF transparency repair tool. Converting one frame does not restore transparency already flattened in the GIF, preserve the animation, or prove that another application will encode frames as required.
When deciding, write down the target background, whether a halo is acceptable, which viewer will be used, and whether animation is mandatory. Those requirements determine whether white output is a valid design choice or a reason to use different software.
Keep transparency and frame sizing as separate diagnoses
Changing the first frame can change the animation's dimensions, but it cannot bypass the white fill. The current tool takes the first image's natural width and height, creates every later frame at that size, and stretches each later image across the full canvas.
For example, if the first input is 64 by 64 and the second is 128 by 64, the output remains 64 by 64 and the second image is compressed horizontally. Its transparent pixels will still become white. Reordering those two files would instead produce a 128 by 64 canvas and stretch the first image, while still flattening both frames over white.
Use equal dimensions and matching aspect ratios for the transparency test so stretching cannot distract from the corner check. If the final material has mixed sizes, prepare copies with a deliberate common canvas in an image editor before adding them. The GIF page has no crop, fit, position, or padding controls and cannot decide which content may be cut or stretched.
Frame order also remains the selection order. The list lets you remove a frame but not drag it to a new position. If the order is wrong, remove the affected items and add prepared copies again in the intended sequence; do not treat a changed first frame as a transparency remedy.
Diagnose common failure symptoms without overwriting evidence
White corners, distorted frames, and a disabled button have different causes. Keep the original images unchanged and use copies while narrowing the problem.
- The page looks white, but the download reveals the dark background: the page surface caused the visual impression; transparency may still be present in that particular file. Record the downloaded-file observation rather than the page screenshot.
- The downloaded corners remain white everywhere: that matches the current canvas-fill behavior. Accept a documented white matte or move to a workflow with verifiable transparency support.
- Later frames look stretched: compare their pixel dimensions and aspect ratios with the first frame. Prepare matching canvases outside the GIF maker; changing the delay cannot repair geometry.
- Generate stays disabled: confirm that at least two valid image files appear and that both have finished loading. Remove a failed item and add a file that opens normally instead of repeatedly clicking the disabled control.
- The old preview disappears after a setting change: the component invalidates the prior result when frames, delay, or loop settings change. Generate and download a new file, then check that copy rather than reusing the old one.
- The tab slows down or runs out of memory: reduce frame dimensions or test fewer frames. Images and encoded output remain in page memory during use, and the tool sets no promise that an arbitrarily large sequence will succeed.
The tool accepts one shared delay from 50 to 5000 milliseconds and offers Forever, 1, 3, or 5 in its loop menu. It does not provide individual frame timing. Loop playback can also vary by viewer, so reopen the downloaded file in the intended destination rather than assuming the in-page preview is definitive.
Verify the deliverable, not just the controls
A useful acceptance check records input evidence and output evidence together. For the two-frame sample, keep the source names, both 64 by 64 dimensions, 300-millisecond setting, loop choice, output filename, output dimensions, and the observed corner behavior over a dark background.
Then inspect both frames for the central shapes, correct order, stretching, unexpected cropping, and edge halos. If white is approved, verify that it is consistent rather than slightly different whites inherited from prepared source files. If transparency is required, an opaque corner is enough to reject this workflow; adding the remaining production frames cannot fix the underlying fill step.
The component reads selected images in the browser and uses locally served gif.js files for encoding. It does not upload the selected image bytes in this path, but downloaded files and screenshots remain on the device, and browser extensions or shared screens are outside the component's control. Use non-sensitive controls for troubleshooting and follow your organization's handling rules for production images.
Common questions
The answers below apply to the currently inspected ToolboxHub component, not every GIF application.
Can a transparent PNG stay transparent in this GIF maker?
No. The current component fills each frame canvas white before drawing the PNG, and it has no switch to disable that fill.
Will putting a transparent image first fix the background?
No. The first image controls output width and height, while the white fill is applied to every frame. Those are separate behaviors.
Does a white preview prove the downloaded GIF is opaque?
No. Download the file and inspect it over a contrasting background. The current source predicts opaque white, but the deliverable itself is what you must accept or reject.
Can I rename the GIF to PNG to recover transparency?
No. Renaming an extension does not convert pixel data or preserve animation. Return to the unchanged source frames and use an appropriate encoder.
Why does Generate require two images?
The current interface disables generation until at least two frames have loaded. A single still image is not accepted as an animation in this workflow.