Pixelate image calculator
A 1920 × 1080 image cut into 16-pixel blocks needs 120 columns by 68 rows, 8160 blocks in all, and its last row is only 8 pixels tall. Plan the grid of a pixelation effect before touching any colors. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Width
- 1,920
- Height
- 1,080
- Block size
- 16
- Columns
- 120
- Rows
- 68
- Total blocks
- 8,160
- Right edge width
- 16
The pixelate image calculator converts an image width, image height, and square block size into the exact grid needed for a pixelation effect. It reports the number of block columns and rows, the total block count, and the dimensions of partial blocks along the right and bottom edges. This is useful when planning a filter, generating a mosaic, estimating work, or matching a design preview to implementation. The calculation is deterministic and runs without uploading or decoding an image.
Turn pixel dimensions into a block grid
A pixelation effect replaces groups of nearby source pixels with a single representative color. Before processing colors, an implementation needs to know how many groups fit across and down the image. Enter the image width and height in pixels, then choose the side length of each square block.
The calculator divides each dimension by the block size and rounds upward. Rounding upward matters because an image dimension is not always an exact multiple of the chosen size. For example, a narrow remainder on the right still needs its own block column; discarding it would leave an unprocessed strip.
The tool calculates geometry only. It does not read image data, sample colors, resize files, or produce a transformed image, so the same inputs always produce the same result without any dependency on image format.
Understand partial blocks at the edges
When both image dimensions divide evenly by the block size, every grid cell has identical dimensions. Real image sizes often leave a remainder, however. The final column may be narrower than the requested block size, and the final row may be shorter.
If there is no remainder, the corresponding edge value equals the full block size rather than zero, because the last block is a normal full block. If there is a remainder, the edge value is exactly the number of source pixels left over. The grid still uses ceiling division, so every source pixel belongs to one and only one cell.
This is particularly helpful for implementations that crop sampling rectangles, allocate tile buffers, or verify that calculated regions never extend beyond the original image bounds.
Choose a valid and useful block size
Width, height, and block size must be positive integers because the calculator models discrete source pixels. The block size must also fit within both image dimensions. Within the valid range, smaller blocks preserve more recognizable detail and create more grid cells; larger blocks produce a coarser abstraction with fewer cells.
You can compare several sizes to balance appearance against processing work before running an actual image filter. For responsive previews, calculate again whenever the source dimensions or desired block size changes rather than scaling an old grid count, since rounding at the edges can change the number of rows or columns. Neither route uploads image pixels because only numeric dimensions are required, making the calculator appropriate for private assets and early planning stages.
What you can do with it
Plan a canvas pixelation loop
Get exact row and column bounds before sampling and painting square color regions on a canvas.
Estimate mosaic workload
Use the total block count to compare the processing work created by several candidate block sizes.
Handle uneven image edges
Use the reported right and bottom edge sizes to avoid cropping pixels or reading beyond image bounds.
FAQ
Why is a block larger than the image rejected?
The capability requires a square block to fit within both image dimensions.
How many blocks does a 1920 × 1080 image make with 16-pixel blocks?
It makes 120 columns by 68 rows, so 8160 blocks. The columns divide evenly, but 1080 is not a multiple of 16, so the bottom row is only 8 pixels tall.
Why does the calculator round up instead of down?
Because a narrow strip left over on the right or at the bottom still needs its own blocks. Rounding down would leave that strip unprocessed, while rounding up puts every pixel in exactly one block.
Which block size should I choose?
Smaller blocks keep more recognizable detail and create more blocks; larger blocks give a coarser, more abstract look with fewer of them. Try several sizes and compare the counts before you run the real filter.
Does the tool pixelate my photo?
No. It only works out the geometry of the grid from the width, the height and the block size. It never opens the picture, samples colors or creates a new file, so the same numbers always give the same grid.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/image/pixelate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"width":1920,"height":1080,"block_size":16}'const res = await fetch("https://api.kit.forhosting.com/image/pixelate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"width": 1920,
"height": 1080,
"block_size": 16
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/image/pixelate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"width": 1920,
"height": 1080,
"block_size": 16
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/image/pixelate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"width":1920,"height":1080,"block_size":16}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"width":1920,"height":1080,"block_size":16}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/image/pixelate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"width": 1920,
"height": 1080,
"block_size": 16
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "image.pixelate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 15 |
max_megapixels | 12 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Turn pixel dimensions into a block grid
The returned columns and rows describe the complete grid, while total_blocks is their product.
Understand partial blocks at the edges
The right_edge_width and bottom_edge_height results make those boundary conditions explicit. This convention makes rendering code straightforward: ordinary cells use block_size, while the final column and row use the reported edge measurements.
Choose a valid and useful block size
A square larger than either side cannot form the requested pixelation grid, so that input returns an invalid_input error instead of an ambiguous result. The browser version performs the calculation locally, while automated API requests cost $0.002 each.
Technical questions
How are the grid columns and rows calculated?
Each image dimension is divided by block_size and rounded up, ensuring that partial blocks at the right or bottom edge are included.
What happens when the dimensions divide evenly?
The edge measurements equal block_size because the last column and row contain full-sized blocks.
Does this tool modify or upload my image?
No. It accepts only width, height, and block_size values and calculates grid geometry without reading an image file.
What does the API request cost?
Each API request costs $0.002. The same deterministic calculation is available free in the browser.