DEV Community: BeGoodTool.com

A "maintenance margin ratio" isn't one formula — it's two, and mixing them up gives you the wrong liquidation price

BeGoodTool.com — Wed, 29 Jul 2026 07:02:21 +0000

I put together a margin call calculator for leveraged stock positions after realizing I kept doing the same algebra by hand every time a family member asked "so at what price do I get a margin call." Simple enough, I thought — one formula, plug in the numbers. Then I actually tried to support both Taiwan-style brokers and US/EU-style brokers in the same tool, and found out they don't even define "maintenance ratio" the same way. Same underlying risk, two different formulas, and if you solve the wrong one for price you get a number that's confidently wrong.

Two formulas hiding behind one label

Taiwanese, Chinese, and Korean brokers report something usually called "整戶擔保維持率" (overall collateral maintenance ratio): total position value divided by the outstanding loan. A healthy account sits around 166%. US/EU brokers instead report an equity percentage: (value minus debt) divided by value. A healthy account there might be 40%. Both numbers describe the exact same account state — they're just expressed as different ratios, and a 30% equity ratio is not "worse" than a 166% collateral ratio, it's the same leverage described from the other side of the fraction.

The tool branches on that explicitly:

const isAsianMode = computed(() => {
  return ["tw", "cn", "kr"].includes(locale.value);
});

const now_maintenance_ratio = computed(() => {
  if (!now_price.value || !buy_quantity.value || !financing.value) return 0;

  let currentTotalValue = now_price.value * buy_quantity.value;
  let loanAmount = financing.value - maintenance_margin.value;

  let res = 0;
  if (isAsianMode.value) {
    // Total market value / loan amount (e.g. 166%)
    res = (currentTotalValue / loanAmount) * 100;
  } else {
    // (Total market value - loan) / total market value (e.g. 40%)
    // i.e. Equity / Total Value
    let equity = currentTotalValue - loanAmount;
    res = (equity / currentTotalValue) * 100;
  }

  return Math.ceil(res * 100) / 100;
});

Locale isn't just a UI label swap here — it changes which formula actually runs, and the default maintenance ratio the input starts at (130% for the Asian mode, 30% for the Western mode) is set by a watcher on locale for exactly that reason. Type a "30" into the Asian branch by mistake and the tool will treat it as an account already deep past liquidation, because 30% collateral coverage would mean the loan is more than three times the position value.

Solving the same inequality for price, from both directions

The actual point of the tool isn't showing you today's ratio — you can compute that from your brokerage app already. It's rearranging the ratio formula to solve for the price where the ratio crosses the danger line, which is a bit more algebra than most people want to do by hand mid-panic. The source comments actually spell out both derivations, so I'll just show them as written:

const gg_price = computed(() => {
  if (!financing.value || !buy_quantity.value) return 0;

  let loanAmount = financing.value - maintenance_margin.value;
  let ratioDecimal = maintenance_ratio.value / 100;
  let gg = 0;

  if (isAsianMode.value) {
    // Asian derivation: Price * Qty / Loan = 1.3  =>  Price = 1.3 * Loan / Qty
    gg = (loanAmount * ratioDecimal) / buy_quantity.value;
  } else {
    // Western derivation: (Price*Qty - Loan) / (Price*Qty) = 0.3
    // 1 - Loan/(Price*Qty) = 0.3
    // 0.7 = Loan/(Price*Qty)
    // Price = Loan / (0.7 * Qty)
    // General form: Price = Loan / ((1 - Ratio) * Qty)
    gg = loanAmount / ((1 - ratioDecimal) * buy_quantity.value);
  }

  return Math.ceil(gg * 100) / 100;
});

Both branches are the same move — take the maintenance-ratio inequality, substitute Price × Quantity for "current value," and isolate Price — but the Western one needs an extra step because the ratio is defined against value instead of against the loan directly. It's a good reminder that "just solve for x" isn't always symmetric even when the two formulas describe the same thing.

Extra margin reduces the loan, not the equity

There's a modeling decision buried in one line that's easy to read past: loanAmount = financing.value - maintenance_margin.value. When you deposit extra cash after opening the position, the code treats it as paying down the loan balance, not as adding to your equity side of the ledger. Both are mathematically valid ways to represent the same cash injection, but they're not interchangeable inside the ratio formulas above — subtracting it from the loan is what makes the Asian ratio (value / loan) actually go up when you deposit more, since a smaller denominator directly raises the ratio. If it had been added to a separate equity variable instead, the Asian branch's formula would have needed to change shape entirely. Small choice, but it's the one that keeps a single formula valid across "no extra deposit yet" and "already topped up once."

The same subtraction shows up again when solving for how much to deposit to get back to a target ratio (say, restoring to 166% instead of just clearing the 130% floor):

if (isAsianMode.value) {
  // Total / (Loan - Add) = Target  =>  Add = Loan - (Total / Target)
  needValue = loanAmount - currentTotalValue / targetDecimal;
} else {
  // (Total - (Loan - Add)) / Total = Target  =>  Add = Loan - Total * (1 - Target)
  needValue = loanAmount - currentTotalValue * (1 - targetDecimal);
}

Same substitution, just solved for Add instead of Price this time, then floored at 0 with res > 0 ? res : 0 so a position that's already healthy doesn't show a negative "deposit this much" instruction.

Rounding decisions that matter more than they look

Three different roundings show up for three different reasons:

The initial equity (self_provided) is rounded up with Math.ceil — if the exact split leaves a fraction of a currency unit, you should never be shown less equity than you actually need to put in.
The computed loan amount (financing) is rounded down with Math.floor — same logic from the other side, since equity + loan should never silently exceed the position's actual cost.
The liquidation price (gg_price) is rounded up to two decimals with Math.ceil(gg * 100) / 100 — this one's the important one. Rounding a danger threshold down would mean showing a price that's technically still safe once you're actually below the real threshold. Rounding up means the number you're shown is always at least as conservative as reality, never less.

None of these are accidental — they're the difference between "a calculator that's approximately right" and "a calculator that never quietly tells you you're safer than you are."

Where this stays a simplified model

This is a single-stock, single-position calculator, and it says so implicitly by not trying to be anything else — no blended maintenance requirements across a multi-position portfolio, no interest accrual on the loan over time, no transaction fees or taxes eating into the equity side. It also assumes the maintenance ratio you type in is exactly the number your broker actually enforces, which varies by broker, by asset class, and sometimes by how volatile the specific stock has been recently — real brokers adjust maintenance requirements for individual securities, and this tool has no idea that happened unless you update the input yourself. It's also long-only; shorting flips which side of the ledger is "the risk," and this formula set doesn't model that. And in a real forced liquidation, brokers don't always sell your entire position at exactly the computed price — fast, illiquid markets can blow through the calculated liquidation price before the order fully fills, leaving you with a worse outcome than the tidy number above suggests.

I ended up putting the cleaned-up version of this online as a small free tool if you want to run your own numbers without doing the algebra by hand: Margin Call Calculator. No sign-up, works for both the Asian collateral-ratio convention and the Western equity-ratio convention.

Available in other languages

融資維持率計算機 — 繁體中文
融资维持率计算器 — 简体中文
Margin Call Calculator — English
信用買い維持率計算機 — 日本語
신용융자 담보비율 계산기 — 한국어
Calculateur Appel de Marge — Français
Калькулятор Маржин-колла — Русский
Margin Call Rechner — Deutsch
Kalkulator Margin Call — Bahasa Indonesia
Calculadora de Margin Call — Español
Máy Tính Call Margin — Tiếng Việt
เครื่องคำนวณ Margin Call — ไทย
Kalkulator Margin Call — Polski
Margin Call Hesaplayıcı — Türkçe
Calcolatore Margin Call — Italiano
Calculadora de Margin Call — Português
Margin Call Calculator — Nederlands
Калькулятор Margin Call — Українська

Why signed binary ranges are asymmetric (I only really got it after building a converter)

BeGoodTool.com — Wed, 29 Jul 2026 02:00:02 +0000

I've "known" two's complement since a CS101 lecture — flip the bits, add one, done. But I didn't really internalize the range-checking part until I tried to build a small calculator that converts between decimal and N-bit binary (showing 1's and 2's complement side by side), and had to handle arbitrary bit widths instead of the fixed int8/int16/int32 everyone just memorizes.

The part everyone skips: range checking

For an N-bit signed number, the range is asymmetric: -2^(N-1) to 2^(N-1) - 1. For 8 bits that's -128 to 127, not -127 to 127. The reason: there's only one all-zero bit pattern (that's 0), so the "extra" negative slot that would otherwise be wasted on a redundant zero goes to the most negative number instead.

That asymmetry means "does this number fit in N bits" isn't a simple abs(num) <= 2^(N-1) - 1 check — the bound is different depending on sign:

function limitNum(num, numLen) {
  const baseNum = 2 ** (numLen - 1);
  const maxNum = baseNum - 1;   // 127 for 8 bits
  const minNum = 0 - baseNum;   // -128 for 8 bits
  return num > maxNum || num < minNum ? 0 : 1;
}

Miss this and your calculator will correctly accept -128 in 8 bits, but also let +128 slide through as if it fit — or worse, silently wrap around and hand back a nonsense value instead of telling the user it's out of range.

Flip the bits, then add one — except "add one" isn't trivial in string-land

Once a number is in binary, its two's complement is "invert every bit, then add 1." Trivial with actual integers — but I was storing binary as strings (so I could show arbitrary bit widths padded with leading zeros), which means "add 1" has to be done by hand, propagating the carry bit by bit from the right:

function notString(binary) {
  return binary.split("").map(bit => (bit === "0" ? "1" : "0")).join("");
}

function addOne(binary) {
  const bits = binary.split("");
  for (let i = bits.length - 1; i >= 0; i--) {
    if (bits[i] === "1") {
      bits[i] = "0"; // carry the 1, keep going left
    } else {
      bits[i] = "1"; // found a 0, flip it, carry absorbed, done
      return bits.join("");
    }
  }
  return bits.join(""); // all 1s overflowed — technically wraps around
}

This is exactly what a hardware full-adder does when adding 1 to a binary number: propagate the carry until it hits a bit that stops it. Writing it out in string form makes visible something that's normally hidden inside the + operator.

Going backwards is the same trick, reversed

The calculator also needs to go the other direction — from a two's complement bit pattern back to the original magnitude, which is useful when you're staring at a hex dump and need to know what negative number it actually represents. It's the same two operations, just chained to get back to source:

function fromTwosComplement(complement) {
  const inverted = complement.split("").map(bit => (bit === "0" ? "1" : "0")).join("");
  return (parseInt(inverted, 2) + 1).toString(2);
}

Invert, add one, done. Two's complement is its own inverse operation, which is a big part of why nearly every CPU uses it: subtraction becomes addition of a complement, so there's no separate circuitry needed just for negative numbers.

Where I actually use this

I don't reach for a two's complement calculator often, but the few times a year I do — debugging a serialization bug, or double-checking a bitwise op in a language with unfamiliar int-width rules — it's genuinely useful to see binary, 1's complement, 2's complement, and decimal side by side instead of working it out by hand or trusting a REPL's implicit int width. I cleaned up the version I built for that into a small free tool: Two's Complement Calculator. No sign-up, works for any bit width you throw at it.

Available in other languages

二進制補數計算機 — 繁體中文
二进制补码计算器 — 简体中文
Two's Complement Calculator — English
2の補数計算機 — 日本語
2의 보수 계산기 — 한국어
Calculateur de complément binaire — Français
Калькулятор двоичного дополнительного кода — Русский
Zweierkomplement-Rechner — Deutsch
Kalkulator Komplement Bilangan Biner — Bahasa Indonesia
Calculadora de Complemento a Dos — Español
Máy Tính Bù Số Nhị Phân — Tiếng Việt
เครื่องคำนวณคอมพลีเมนต์เลขฐานสอง — ไทย
Kalkulator uzupełnień liczb binarnych — Polski
İkili Tamamlayıcı Hesap Makinesi — Türkçe
Calcolatrice di Complementi Binari — Italiano
Calculadora de Complemento de Dois — Português
Binaire Aanvullingscalculator — Nederlands
Калькулятор Доповнень Двійкових Чисел — Українська

Turns out "fancy Instagram fonts" are just Unicode — here's how I built a generator for it

BeGoodTool.com — Tue, 28 Jul 2026 09:01:37 +0000

A while back someone half-jokingly asked if I could make a tool that turns "hello" into "𝓱𝓮𝓵𝓵𝓸" for their Instagram bio. My first instinct was "that's just a custom font" — but it's not. You can't swap fonts inside a plain text field on Instagram, TikTok, or Discord. So how do all those stylized bios actually work?

Turns out the trick has nothing to do with fonts. It's Unicode.

The block nobody tells you about: Mathematical Alphanumeric Symbols

Unicode reserves a whole range (U+1D400–U+1D7FF) called Mathematical Alphanumeric Symbols. It exists so mathematicians can write 𝐀 (bold), 𝐴 (italic), 𝒜 (script), 𝔄 (fraktur) as genuinely distinct characters instead of relying on rich-text formatting. Nothing stops you from typing them into a regular text field, though — they render exactly like normal text, no font, no app support required.

So a "fancy font converter" is really just a character-substitution cipher against a lookup table. For every style I built a 62-character string covering A–Z, a–z, 0–9, mapped 1:1 onto the matching styled code points:

const chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

const fontsMapping = [
  { id: "serifBold", map: "𝐀𝐁𝐂𝐃𝐄𝐅𝐆𝐇𝐈𝐉𝐊𝐋𝐌𝐍𝐎𝐏𝐐𝐑𝐒𝐓𝐔𝐕𝐖𝐗𝐘𝐙𝐚𝐛𝐜𝐝𝐞𝐟𝐠𝐡𝐢𝐣𝐤𝐥𝐦𝐧𝐨𝐩𝐪𝐫𝐬𝐭𝐮𝐯𝐰𝐱𝐲𝐳𝟎𝟏𝟐𝟑𝟒𝟓𝟔𝟕𝟖𝟗" },
  { id: "fraktur",    map: "𝔄𝔅ℭ𝔇𝔈𝔉𝔊ℌℑ𝔍𝔎𝔏𝔐𝔑𝔒𝔓𝔔ℜ𝔖𝔗𝔘𝔙𝔚𝔛𝔜ℨ𝔞𝔟𝔠𝔡𝔢𝔣𝔤𝔥𝔦𝔧𝔨𝔩𝔪𝔫𝔬𝔭𝔮𝔯𝔰𝔱𝔲𝔳𝔴𝔵𝔶𝔷0123456789" },
  // ...30 more of these
];

function convertString(str, font) {
  const mapArray = Array.from(font.map); // Array.from, not split() — more on that below
  let result = "";
  for (const char of str) {
    const index = chars.indexOf(char);
    result += index !== -1 && mapArray[index] ? mapArray[index] : char;
  }
  return result;
}

Two things bit me while building this:

1. Array.from() instead of .split(''). A lot of these code points live above U+FFFF, so they're encoded as surrogate pairs in JS strings. map.split('') slices a pair in half and hands you back mangled characters. Array.from() iterates by code point, which is what you actually want here.

2. Not every style has a full alphabet. Some Unicode "fonts" — small caps, superscript, the currency-symbol style — only exist for a subset of letters. There's no true Unicode superscript "Q," for instance, so I substituted the closest visual look-alike from a completely different block. For those styles it's not really a clean 1:1 cipher, it's closer to visual forgery.

The weird one: Zalgo text

The glitch/cursed-text effect (t̸h̶i̵s̴ ̶s̴o̷r̶t̵ ̶o̴f̵ ̸t̶h̷i̴n̶g̸) isn't from the same character block at all — it's combining diacritical marks. Normally these stack a single accent on top of a letter (the mark that turns e into é). Nothing stops you from stacking dozens of them on the same character:

const zalgoUp   = ["̍", "̎", "̄", /* ...36 more */];
const zalgoMid  = ["̕", "̛", "̀", /* ... */];
const zalgoDown = ["̖", "̗", "̘", /* ... */];

for (const char of str) {
  result += char;
  const numUp = Math.floor(Math.random() * 2) + 1;
  for (let j = 0; j < numUp; j++) {
    result += zalgoUp[Math.floor(Math.random() * zalgoUp.length)];
  }
  // same idea for the mid and down mark sets
}

Randomly stack 1–2 marks above, 0–1 in the middle, and 1–2 below every character, and you get the "reality is glitching" look. It's not elegant — it's controlled chaos — but the randomness is exactly what sells the effect.

The other decorations are combining marks too

Strikethrough, underline, and overline use the same combining-character trick, just with a single mark appended after each letter instead of a lookup substitution:

{ id: "strikethrough", decorator: "̶" },
{ id: "underline",     decorator: "̲" },

"h" + "̶" renders as h̶. No lookup table needed — just append and skip spaces, since a combining mark attached to a space usually renders oddly or gets silently dropped by the renderer.

Why this breaks more than it should

Once you know the trick, the limitations make sense:

These are still plain Unicode characters to a screen reader, not letters — text-to-speech often can't pronounce them correctly.
Search engines and in-app search generally won't match "𝓱𝓮𝓵𝓵𝓸" against "hello," so you lose searchability the moment you use it.
Devices or fonts missing glyphs for the rarer blocks fall back to the classic empty box (☒).

None of that stops it from being fun — but it's worth knowing you're trading "cool font" for "no longer quite text" in the eyes of most software that touches it.

I turned the whole thing (30+ styles plus the Zalgo generator) into a small free tool if you want to play with it without building your own lookup table: Instagram Font Generator. No sign-up, it's a static page.

Available in other languages

Instagram字體轉換器 — 繁體中文
Instagram字体生成器 — 简体中文
Instagram Font Generator — English
Instagramフォント変換ツール — 日本語
인스타 폰트 변환기 — 한국어
Polices Instagram — Français
Шрифты для Instagram — Русский
Instagram Schriftarten — Deutsch
Generator Font Instagram — Bahasa Indonesia
Fuentes para Instagram — Español
Phông chữ Instagram — Tiếng Việt
เปลี่ยนฟอนต์ Instagram — ไทย
Czcionki Instagram — Polski
Instagram Yazı Tipleri — Türkçe
Font per Instagram — Italiano
Fontes para Instagram — Português
Instagram Lettertypen — Nederlands
Шрифти для Instagram — Українська