Input Format Interpretation and Still Image Process via Browser API
The image loading mechanism of this tool is built upon the integration of the File API and Canvas API specified in HTML5. You can input up to 50 images at once, with a maximum file size of 30MiB per image.
Image files selected by the user from their local device are not transmitted to an external server as image data, but are expanded directly into the browser's memory space as Blob (Binary Large Object) data.
This Blob data undergoes a process where it is parsed by the browser's internal image decoder and rendered as pixel data onto the canvas context.
A significant constraint in this rendering process is the browser's decoding behavior. While typical web browsers can display multiple input formats, this tool, which redraws and outputs to the Canvas, does not carry over all frames and playback times of animations.
Even if an animated GIF is input, it is output as a single still image decoded by the browser at the time of rendering, so it cannot be used for animation conversion.
Furthermore, the behavior regarding input images with an alpha channel (transparency information) depends on the format upon output.
In the input stage, the RGBA (Red, Green, Blue, Alpha) channels are expanded in memory, but during the processing, the canvas background is treated as transparent by default.
The transparent state is maintained at the point when a PNG image containing transparent pixels is loaded; however, if a format that does not support transparency is selected in the encoding process described later, those pixels are integrated by blending with a default composite color (often black or a browser-dependent background color).
Users must verify this conversion to still images and color space handling beforehand when processing logos or icons that require transparency.
Note that strict color retention is not guaranteed.
Ratio Specification and Custom Dimension Calculation Logic During Redraw
The core part of image resizing lies in the redrawing process that remaps the pixel grid of the original image into a grid of new dimensions.
In this implementation, the tool provides users with two interfaces: "reduction by ratio (% specification)" and "custom dimension specification in pixels", each determining the size of the target drawing area using a different logic.
When the "reduction by ratio" mode is selected, the tool uses the original resolution (original width and height) of each currently selected individual image as the base value.
It retrieves a scale value from 10% to 150% (in 5% increments) from the provided slider interface and multiplies it against each of the original dimensions.
The resulting floating-point numbers undergo processing to become integers in order to fit the discrete unit of pixels. This method functions effectively when applying relative reduction or enlargement to each image in situations where multiple images with different resolutions are loaded simultaneously.
On the other hand, in the "pixel specification" mode, the canvas dimensions are determined based on the width and height specified by the user in the input fields.
Note that when "Fix aspect ratio" is active, the custom dimension calculation is based on the side that was last edited, and it calculates the other dimension using each individual image's original aspect ratio.
Custom input values are processed by parseInt, which extracts the integer part, meaning a value like 12.9 becomes 12. If the conversion fails or results in a value of 0 or less, the original dimensions are used.
Also, changing the settings discards the old results and does not update the processed images; you must execute the conversion again after making changes.
Characteristics and Selection Criteria of Output Formats (JPEG, PNG, WebP)
In the phase where the pixel array redrawn on the canvas is output again as a file, this tool calls the encoder built into the browser.
By implementation, JPEG, PNG, and WebP are provided as the main formats capable of being output, each having different data structures and compression characteristics.
If a browser falls back to PNG when it cannot encode the requested format, the download uses a .png extension.
The JPEG (image/jpeg) format is a standard lossy compression format widely used for images that utilize many photographs or gradients.
It reduces file size by thinning out high-frequency components utilizing human visual characteristics, but it does not have the ability to retain transparency information (alpha channel).
Therefore, if a transparent PNG or similar is output as a JPEG, the transparent parts will be filled with an opaque color.
The PNG (image/png) format is a format that adopts a lossless compression algorithm (Deflate) and has the characteristic of being able to retain the pixel's color information and alpha channel.
It is suitable for maintaining the sharpness of boundaries after resizing or the clear quality of screenshots containing text; however, when applied to images with a large number of colors like photographs, the generated file size tends to become enormously large compared to other formats.
In this tool's implementation, if the PNG format is selected, the quality parameter specified later is undefined for the encoder and ignored, performing lossless compression without quality degradation.
The WebP (image/webp) format is a highly efficient format that has become widely supported by modern browsers, supporting both lossy and lossless compression, as well as retaining the alpha channel within a single standard.
It often has superior compression efficiency compared to JPEG and is a recommended choice in situations where capacity reduction is prioritized, such as for website publication.
Users need to judge and apply the appropriate format from the drop-down menu, considering the intended use of the final output image.
Note that WebP at 100 quality does not guarantee lossless compression.
Correlation Between Quality Parameter and Generated Capacity
In the compression of image data, file size and visual clarity are in a trade-off relationship. In this tool, when output in JPEG or WebP format is selected, a slider interface that specifies the image quality from 10 to 100 becomes active.
This numerical value is converted into an argument from 0.0 to 1.0 that is ultimately passed to the Canvas output method, functioning as a parameter to instruct the degree of compression to the browser's built-in encoder.
When the quality value is set to 100, the encoder behaves to suppress visual quality degradation, but this does not mean uncompressed; it means high-quality lossy compression is performed within the framework of the set format.
As the numerical value is lowered, adjacent pixel groups in the image are approximated in larger block units, and quantization of color information is strongly applied.
Especially in JPEG output set to a low quality value, unwanted artifacts are likely to occur around boundaries, and blocky boundaries become visible in flat areas.
What should be noted here is the calculation logic for the capacity difference displayed on the screen. On the preview screen, it compares the Blob size obtained by actually processing the selected image with the original file size.
Even if the pixel dimensions are halved, depending on the original image's compression efficiency and output quality, the converted file size might be larger than the original.
Since there is no function to predict capacity in advance and automatically adjust to a target value, execute the process again after changing the settings and compare the updated capacity with the appearance.
Sequential Processing Pipeline for Multiple Images and Individual Save Mechanism
When multiple image files are dropped into the drop area, this tool manages them as an internal list and activates the processing pipeline triggered by pressing the "Convert and resize all images at once" button.
This bulk processing is a sequential processing mechanism that applies the current parameters (dimensions, format, quality value) set on the UI as a common rule to all files registered in the list, and executes rendering on the Canvas and Blob generation one by one through the program's loop process.
Note that there is an upper limit of 8192 pixels per edge and 16,777,216 total pixels, with exception failures sent to the error state.
Both of these conditions must be satisfied for processing to proceed. Processing completion is not necessarily notified as a success, so you must check for individual errors within the list interface.
When the processing is complete and the "Download converted image" action is called, a temporary Object URL is generated from the Blob data of each generated file.
The file extension is determined by the actualBlob.type; so a PNG blob uses the .png extension. Additionally, GIF format remains a static image, and JPEG format maintains the image without white background compositing.
As the implementation of the save function, a method is adopted where invisible link elements are dynamically generated on the browser, and the download is initiated by programmatically triggering click events sequentially for each image.
While this method enables immediate file transfer, caution is required depending on the user's browser security settings. The behavior of attempting to download a large number of files continuously at extremely short intervals may be detected by the browser as "automatic download of multiple files," temporarily blocking the saving of the second and subsequent images and potentially displaying a dialog asking the user for permission.
Bulk saving provides individual links and does not create a ZIP file. Also, each downloaded file name is generated with a specified string and a new extension added to the end, based on the original image's file name.
Since this results in a large amount of files being saved as individual files in the download folder, prior folder organization is recommended.
Disposal of Metadata and Memory Resource Constraints in the Execution Environment
Original images taken with digital cameras or smartphones may have various metadata attached as Exif information, such as shooting date and time, GPS location information, camera model settings, and ICC profiles (color management information).
In the image processing architecture via the Canvas API adopted by this tool, the image is decoded and re-encoded. While the browser may perform color processing during decoding, the Canvas output does not guarantee the preservation of the original Exif or ICC profiles as is.
This tool is not a dedicated utility for verifying complete metadata removal, and it does not guarantee the prevention of location information leakage or strict color management.
Conversely, it may result in a loss of information for purposes where you want to maintain photo shooting records or strict color profiles, so judgment before processing is essential.
Furthermore, the characteristic that the processing depends on the user's execution environment (client-side) means it is subject to constraints by the terminal's hardware resources.
Web browsers set a limit on the memory allocated per tab, and when an image with a high pixel count (such as a file reaching tens of millions of pixels) is loaded and expanded onto the Canvas, it consumes a large amount of memory as an uncompressed array.
If massive images are registered in the list simultaneously (keeping in mind the limit of up to 50 images at 30MiB each) and preview rendering for comparison is performed in parallel, the browser's memory management may not keep up, creating a risk of tab crashes or forced page reloads.
Although this tool's implementation incorporates a mechanism to discard generated unnecessary Object URLs to prevent memory pressure, it has no resistance against processing requests that exceed physical memory constraints.
Therefore, in mobile device environments like smartphones with small memory capacities or when handling images with extremely high resolutions, the system design requires operational ingenuity on the user's part, such as limiting the number of images processed at once to a few, or securing resources by closing other applications or tabs running in the background.