#Pricing

Transcodely uses a transparent, multiplier-based pricing model. The cost of a transcoding job is determined by the input duration, the codec, resolution, framerate, quality tier, and any premium features of each output. Prices are locked at job creation time — if pricing changes after you submit a job, your cost does not change.

#How Billing Works

Usage is invoiced monthly in arrears, on calendar months. Everything a job costs — output costs, the processing fee, and separately metered services — accrues to the month it ran in. That period closes at the end of the month, and the invoice for it is charged to your payment method on the 1st, for the month just ended. There is no subscription fee and nothing is prepaid: an organization that ran no jobs owes nothing. Polar’s customer portal may still show a monthly plan against your organization — that is the €0 shell your metered usage is billed against, not a recurring charge.

Invoices and receipts are sent to the organization’s billing_email, which must be set before a payment method can be added. Add the payment method itself from the Billing page in the dashboard — it opens Polar’s hosted portal, where the card is entered and stored.

Whether an organization has a usable payment method also decides which limits apply to it; see Billing Standing. The full commercial terms are in the Terms of Service.

#Cost Formula

The cost per output is calculated as:

output_cost = (duration_minutes) x base_price x codec_mult x resolution_mult x framerate_mult x quality_mult x feature_mult

The total job cost is the sum of all output costs.

#Codec Multipliers

Different codecs have different computational costs, and each also has its own base price per minute — so AV1 costs more per minute than H.264 even though their multipliers are the same:

#Resolution Multipliers

Higher resolutions require more processing:

Custom dimensions are mapped to the nearest resolution tier based on pixel count.

#Framerate Multiplier

The framerate multiplier scales linearly from a 30fps baseline:

framerate_mult = actual_framerate / 30

If the framerate is set to 0 (keep original), the actual framerate from the input probe is used.

#Quality Tier Multiplier

#Feature Multipliers

Premium features apply an additional multiplier on top of the base cost. When no premium features are enabled, the feature multiplier is 1.0 and has no effect.

When multiple premium features are active on the same output, their multipliers are multiplied together to form a single cumulative feature_mult. The overlay multiplier is the one exception to “stacks per feature”: it is a single class covering both the logo watermark and burned-in subtitles, so any output with at least one pixel-burning overlay carries exactly one 1.1x — enabling both does not compound to 1.21x.

#Price Locking

All pricing multipliers are captured in a pricing snapshot when a job is created. This snapshot is immutable — even if base prices or multipliers are updated later, your job’s cost is calculated using the original snapshot.

{
  "pricing": {
    "base_price": 0.01,
    "codec_multiplier": 1.0,
    "resolution_multiplier": 1.0,
    "framerate_multiplier": 1.0,
    "quality_multiplier": 1.0,
    "resolution_tier": "1080p",
    "actual_framerate": 30,
    "pixel_count": 0,
    "feature_multiplier": 1.0
  }
}

#Estimated vs Actual Cost

Costs are calculated at two points in a job’s lifecycle:

The estimated cost is available in the awaiting_confirmation state for delayed-start jobs, allowing you to review costs before encoding begins.

#Example Calculation

A 10-minute video encoded to H.264 1080p at 30fps with standard quality:

cost = 10 min x €0.01 x 1.0 (H.264) x 1.0 (1080p) x 1.0 (30fps) x 1.0 (standard) x 1.0 (no features)
     = €0.10

The same video at 4K AV1 premium quality (note AV1’s higher €0.04 base price):

cost = 10 min x €0.04 x 1.0 (AV1) x 4.0 (4K) x 1.0 (30fps) x 2.0 (premium) x 1.0 (no features)
     = €3.20

#Multi-Output Pricing

Jobs with multiple outputs are priced per-output. Each output has its own pricing snapshot and cost calculation:

{
  "total_estimated_cost": 0.225,
  "outputs": [
    {
      "estimated_cost": 0.10,
      "pricing": { "codec_multiplier": 1.0, "resolution_multiplier": 1.0, "..." : "..." }
    },
    {
      "estimated_cost": 0.125,
      "pricing": { "codec_multiplier": 1.0, "resolution_multiplier": 1.5, "..." : "..." }
    }
  ]
}

#Per-Variant Pricing (ABR)

For adaptive streaming outputs (HLS/DASH) with multiple video variants, each variant is priced individually — its own codec, resolution, and quality drive a separate cost — and the entries are returned in the output’s variant_pricing array. The output’s estimated_cost is always the sum of these per-variant costs (the same holds for actual_cost):

{
  "outputs": [
    {
      "estimated_cost": 0.225,
      "variant_pricing": [
        {
          "index": 0,
          "codec": "h264",
          "resolution": "1080p",
          "quality": "standard",
          "estimated_cost": 0.10,
          "status": "completed",
          "progress": 100
        },
        {
          "index": 1,
          "codec": "h264",
          "resolution": "720p",
          "quality": "standard",
          "estimated_cost": 0.075,
          "status": "processing",
          "progress": 65
        },
        {
          "index": 2,
          "codec": "h264",
          "resolution": "480p",
          "quality": "standard",
          "estimated_cost": 0.05,
          "status": "pending",
          "progress": 0
        }
      ]
    }
  ]
}

#Processing Fee

Encoding capacity is dedicated per job. A job is scheduled onto a machine sized to the renditions it asked for, and that machine encodes that job and nothing else until it finishes. The processing fee is the price of starting that machine: one flat charge per job an encoder picks up, scaled to the size class the job was sized onto.

total = processing_fee_eur + sum of output costs + fees

Every term is additive. The processing fee does not clamp, replace, or absorb anything — it is one more line on the bill, and the per-output invariant is untouched: each output’s cost is still exactly the sum of its variant costs.

The fee is locked at job creation, like the pricing snapshot: the rate quoted when the job is created is the rate you are billed, even if the published rate moves afterward. It rides the wire as an entry in the job’s fees array with fee_type processing, unit job, and quantity 1, and appears on the job’s cost breakdown as its own Processing fee line.

Current rates by size class:

These are the current rates and are runtime-configurable; the pricing page is always authoritative for what is charged today.

#What the fee is billed on

Failed jobs bill €0 — outputs, processing fee and all.

Canceling a job that is still queued costs nothing. The fee applies once an encoder picks the job up, meaning the job has left pending. From that point a cancel bills the processing fee plus any outputs that completed before the cancel landed: the machine was already running. Declining a delayed-start job after its probe has run also bills the fee, because the probe ran on real hardware.

Additive fees — AI captions, for instance — are separate metered services billed on top of the processing fee, and only when the resulting file was actually delivered. Neither fee absorbs the other.

All processing-fee amounts are in EUR.

Historical: the per-job minimum charge. Jobs created before August 2026 were billed under a per-job minimum charge rather than a processing fee: the job total was max(sum of output costs, minimum_charge_eur), where the minimum was the sized machine’s hourly price × 1.25. Those jobs keep the terms they were created under, and their minimum_charge_eur and minimum_charge_applied fields still render on their cost breakdowns. Both fields are deprecated and are absent (or false) on every job created under the processing-fee model. No new job is subject to a minimum charge.

#Currency

All job costs are currently denominated in EUR — the organization’s billing currency setting is not yet consulted for job pricing. The currency field on every job indicates which currency the cost fields use.

#Cost Estimation Before Submission

Use the estimated_cost_per_minute field on Presets to estimate costs before submitting a job. Multiply this value by your input duration to get an approximate cost.

For precise estimates, use delayed start — the job will probe the input and provide exact cost estimates before encoding begins.