Credit utilization ratio calculator
One card with 1,200 owed on a 4,000 limit and another with 800 on 2,000 add up to 33.33% credit utilization, just above the 30% guideline. Enter each card's balance and limit to see the overall and per-card picture. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Credit utilization is the share of revolving credit you have already drawn: outstanding card and line balances divided by the combined credit limits on those same accounts. Lenders and FICO-style scoring models treat that ratio as a major slice of the amounts-owed factor, which is why people search for a credit utilization ratio calculator before they apply for a mortgage or try to lift a mid-range score. Unused limits still count in the denominator, and an over-limit card is allowed so the percent can exceed one hundred.
What credit utilization means and how the ratio is built
Credit utilization is the fraction of revolving credit already in use: add every outstanding balance on credit cards, store cards, and other revolving lines, then divide by the sum of those same accounts' credit limits. Scoring bureaus treat this ratio as a large part of the amounts-owed factor, so a wallet that looks fine as a pile of dollar balances can still look stretched once it is expressed as a percent of available limits.
The identity is not the same as a debt-to-income ratio, a snowball payoff plan, or a Luhn check on a card number: people who type credit utilization ratio calculator want the revolving-limit picture, including cards they are not using. An unused card with a zero balance and a four-thousand limit still enlarges the denominator and lowers the overall percent; closing that card later can raise utilization overnight.
Individual cards can tell a different story from the portfolio: the Mastercard is already at 40 percent while the Visa sits at 30 percent, and FICO-style models look at both overall utilization and per-card utilization. Installment loans, mortgages, and auto notes are not revolving credit and do not belong in this sum.
What you can do with it
Pre-application utilization check
Add every revolving card before a mortgage or auto pull and see how much to pay this cycle to land under the 30 percent or 10 percent guideline.
Counseling and coaching sessions
Show a client the hottest card next to the overall ratio so a maxed store card is not hidden by a large unused limit on another account.
FAQ
How is the credit utilization ratio calculated?
Unused cards still add their full limit to the denominator. A Visa at 1200/4000 plus a Mastercard at 800/2000 is 2000/6000, or about 33.33 percent.
What utilization percent do lenders want to see?
A common consumer guideline is to stay at or under 30 percent overall and on each card; many score-watchers aim under 10 percent.
Do unused credit cards count?
Closing that card later shrinks the denominator and can raise the percent overnight even if you borrowed nothing new.
What if a card is over its limit?
The account still participates in the portfolio totals.
How much do I need to pay down to get under 30%?
Your total balances minus 30% of your total limits. With 2,000 owed on 6,000 of limits, paying 200 brings you to 30%, and paying 1,400 brings you to 10%.
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/finance/credit-utilization \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"accounts":[{"name":"Visa","balance":1200,"credit_limit":4000},{"name":"Mastercard","balance":800,"credit_limit":2000}]}'const res = await fetch("https://api.kit.forhosting.com/finance/credit-utilization", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"accounts": [
{
"name": "Visa",
"balance": 1200,
"credit_limit": 4000
},
{
"name": "Mastercard",
"balance": 800,
"credit_limit": 2000
}
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/finance/credit-utilization",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"accounts": [
{
"name": "Visa",
"balance": 1200,
"credit_limit": 4000
},
{
"name": "Mastercard",
"balance": 800,
"credit_limit": 2000
}
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/finance/credit-utilization", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"accounts":[{"name":"Visa","balance":1200,"credit_limit":4000},{"name":"Mastercard","balance":800,"credit_limit":2000}]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"accounts":[{"name":"Visa","balance":1200,"credit_limit":4000},{"name":"Mastercard","balance":800,"credit_limit":2000}]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/finance/credit-utilization", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"accounts": [
{
"name": "Visa",
"balance": 1200,
"credit_limit": 4000
},
{
"name": "Mastercard",
"balance": 800,
"credit_limit": 2000
}
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "finance.credit_utilization",
"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_accounts | 50 |
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
This tool accepts every revolving account as a row with a balance and a credit_limit, sums both sides, and returns utilization as a decimal ratio and a percent, plus remaining available credit, a band from excellent through over-limit, and the paydown needed to reach the common 30 percent and 10 percent guidelines.
What credit utilization means and how the ratio is built
In symbols, utilization_ratio equals total_balance divided by total_credit_limit, and utilization_percent is that ratio times one hundred. A worked check is a Visa with a twelve-hundred balance on a four-thousand limit and a Mastercard with an eight-hundred balance on a two-thousand limit: combined balances are two thousand, combined limits are six thousand, the ratio is one third, and utilization_percent is about 33.33. That sits just above the common 30 percent guideline, so paydown_to_30 is two hundred and paydown_to_10 is fourteen hundred. When a balance exceeds its limit the account is over-limit, the percent goes past one hundred, and available_credit on that row is zero while over_limit_amount records the excess.
Input contract, response fields, bands, and errors
Optional name labels the row in the per-account breakdown; when it is omitted the engine writes Account 1, Account 2, and so on. One to fifty accounts are accepted. POST a JSON body with one required array, accounts (aliases items, list, and cards). Each row is an object with balance, a finite number greater than or equal to zero (aliases outstanding and amount), and credit_limit, a finite number strictly greater than zero (aliases limit and creditLimit). Optionally set target_percent (alias target) to the guideline used for paydown_to_target; it defaults to 30 and must lie in the open-closed interval (0, 100]. Optionally set decimals to an integer from zero to eight for currency-style totals and utilization_percent; the default is two, while utilization_ratio is always rounded to six places. The engine sums every balance and every credit_limit, forms the ratio, and derives available_credit as the non-negative remainder of limits minus balances, over_limit_amount as the non-negative excess of balances over limits, and the paydown figures as max of zero and balance minus k percent of the combined limits, for k of 10, 30, and the chosen target. band is excellent at or below 10 percent, good at or below 30, fair at or below 50, high at or below 75, very_high at or below 100, and over_limit above 100. Booleans under_10_percent and under_30_percent compare the raw percent against those two guidelines with a tiny epsilon so a wallet sitting exactly on 30 percent is not tripped by floating-point dust. highest_account and highest_utilization_percent flag the hottest card so you can see a maxed store card hiding inside a calm overall ratio. Money-like fields use half-up rounding once from the raw IEEE values so goldens stay byte-stable across runtimes. Missing accounts, an empty list, a non-object row, a missing or non-finite balance or credit_limit, a negative balance, a zero or negative limit, more than fifty rows, or an out-of-range target or decimals fail with invalid_input naming the field and are not billed.
Where a credit utilization calculator earns its keep
Exam-prep and classroom TVM units need a deterministic oracle that treats unused limits as part of the denominator, rejects a zero limit instead of dividing by zero, and returns both the portfolio percent and the hottest card. Pair it with your own bureau extract when the question is what the bureaus already see, and use this calculator when the question is what a known set of revolving balances and limits implies right now. Credit counselors and nonprofit coaches use the endpoint to show a client how much to pay this cycle to land under 30 percent or 10 percent before a mortgage pull, without opening a spreadsheet. Product and underwriting teams batch the JSON API over statement extracts to flag wallets whose overall ratio looks fine while one card sits over-limit. Keep requests small and pin utilization_percent plus paydown_to_30 in tests. This tool does not pull a credit report, does not age the score, and does not model authorized-user tradelines, charge-offs, or the difference between reported statement balances and today's live balance.
Integration use cases
Automation and content widgets
Batch statement rows through the JSON API, or embed the free browser widget on a page that ranks for credit utilization ratio calculator.
Technical questions
What does the credit utilization ratio calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.