Pad to monospace width
Line up columns that mix Latin and East Asian writing: 東京 takes 4 columns, so padding it to 8 adds just 4 spaces, not 6. Wide characters and most emoji count as two columns, combining marks as none. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- 東京
- Width
- 8
- Side
- Right
- Result
- 東京
- Char
- Original length
- 2
- Original visual width
- 4
Padding a string so that columns line up in a terminal is a visual-width problem, not a character-count problem. East Asian ideographs, Hangul syllables, fullwidth Latin letters, and most emoji occupy two columns in a monospace font, while combining marks, variation selectors, and zero-width joiners occupy none. A JavaScript length pad therefore mis-aligns any cell that mixes Latin with Japanese, Chinese, or Korean. This tool measures East Asian Width–style display columns, then inserts a single-column fill character on the left, the right, or both sides until the target column count is reached.
How visual column width is measured
In a typical monospace terminal every ASCII letter, digit, and punctuation mark occupies one column. That mental model breaks as soon as the string contains a character whose East Asian Width is Wide or Fullwidth. CJK Unified Ideographs, Hangul syllables, fullwidth digits such as the ideographic forms of zero through nine, and the fullwidth Latin block each occupy two columns.
Combining marks in category Mn or Me, format characters, Hangul jamo medial vowels and final consonants, variation selectors, and the zero-width joiner occupy zero columns and attach to the preceding grapheme. Regional-indicator pairs that form a flag emoji are treated as a single two-column cluster, and emoji joined with a zero-width joiner stay one cluster of width two rather than a stack of independent pictographs.
Ambiguous-width characters such as Greek letters and some symbols follow the POSIX and Western convention and count as one column, which matches most Linux and macOS terminals outside an East Asian locale. Control characters including tab and newline are rejected: tab width is not a property of the string, and this tool pads one cell, not a whole table. The algorithm walks Unicode code points, never UTF-16 surrogate pairs, so a single emoji outside the Basic Multilingual Plane is one character, not two.
The result is the same column count you would get from a conservative wcwidth-style measurement, which is exactly what you need before you add pad characters so a Japanese name and a Latin SKU share a straight right edge.
Where visual-width padding shows up in real work
CLI authors, log formatters, and anyone who prints a table in a monospace font hit this problem the first time a Japanese, Chinese, or Korean value lands in a column that was sized with string length. Invoice numbers sit next to product names; a CJK name that is two JavaScript characters wide occupies four terminal columns and shoves the price column to the right. Markdown tables, README status boards, and thermal receipt printers have the same constraint whenever a cell mixes scripts.
Data pipelines that emit fixed-width export files for East Asian markets cannot use a character-count pad without breaking the layout the downstream bank or mainframe parser expects. Prefer this page when the search intent is pad to monospace width, visual width, East Asian Width, wcwidth, or aligning CJK columns in a terminal. Ordinary left-pad or zero-pad of ASCII identifiers is a different query and belongs on the character-count pad tool; this landing is for the column-alignment problem that only appears once wide characters enter the cell.
What you can do with it
Align CJK cells in terminal tables
Right-pad mixed Latin and Japanese, Chinese, or Korean cells to a shared visual width so price and status columns stay straight in CLI output.
Fixed-width East Asian export fields
Space-pad product names and addresses to the column budget a legacy fixed-width file expects, counting fullwidth characters as two columns.
Center mixed-script banners
Pad both sides of a short title that contains CJK or emoji so a monospaced receipt line or log header is visually centered.
FAQ
How is this different from ordinary string padding?
Ordinary pad counts JavaScript characters. This tool counts monospace visual columns, so 東京 is width 4, not 2, and columns stay aligned when Latin and CJK share a row.
Can I pad with a fullwidth space or an emoji?
No. The fill character must itself occupy exactly one visual column. Use an ASCII space, 0, hyphen, or another narrow glyph.
How are emoji and flags counted?
Most emoji occupy two columns. A regional-indicator pair (a flag) is one two-column cluster. Zero-width joiner sequences stay one cluster instead of stacking widths.
What does visual-width padding cost?
The browser tool is free and runs locally.
What if my text is already wider than the target?
Nothing is cut. The tool stops and tells you instead of silently trimming your data, so you can choose a wider column. If the widths are equal, the text comes back without any fill.
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/str/pad-visual-width \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"東京","width":8,"side":"right"}'const res = await fetch("https://api.kit.forhosting.com/str/pad-visual-width", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "東京",
"width": 8,
"side": "right"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/str/pad-visual-width",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "東京",
"width": 8,
"side": "right"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/str/pad-visual-width", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"東京","width":8,"side":"right"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"東京","width":8,"side":"right"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/str/pad-visual-width", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "東京",
"width": 8,
"side": "right"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "str.pad_visual_width",
"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_chars | 65536 |
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
When the text is already wider than the target, the request fails with invalid_input instead of silently truncating your data.
What you send and what you get back
Send required fields text, width, and side, plus optional char. Empty text is allowed and produces a pure fill string of the requested width. Optional char is a single code point whose own visual width is exactly one column and defaults to an ASCII space; a fullwidth space or an emoji fill is rejected because a two-column fill cannot hit an odd remaining budget. Numbers and booleans for text are coerced to decimal or true/false strings; objects and arrays are rejected. Classic check: the two-character Japanese city name 東京 has visual width four, so right-padding it to width eight with spaces yields 東京 plus four spaces; left-padding ASCII forty-two to width six with zero still yields 000042, matching ordinary pad for Latin-only input. Text is the cell to pad; aliases input, value, data, s, message, string, content, and body are accepted. Width is the target visual column count, a non-negative integer; aliases target, columns, size, and n work when width is omitted. Side must be left, right, or both, with aliases start or l, end or r, and center or c. Text longer than the documented character cap, or a width above the documented maximum, fails with invalid_input. On success the response echoes text, width, side, and char, plus result for the padded string, original_length and length as JavaScript string lengths, original_visual_width and visual_width as column counts, pad_count, pad_left, pad_right, and operation set to pad_visual_width. Pricing for successful API calls is the published base of $0.002 per item; validation failures including a target below the current visual width are not billed.
Where visual-width padding shows up in real work
Because this capability is a pure parse engine, every successful call costs the published $0.002 base price with no model tokens and no outbound network, and failed validation does not consume balance.
Technical questions
What happens if the text is already wider than the target?
The request fails with invalid_input. This tool never truncates; target width must be greater than or equal to the measured visual width.