Ecoji emoji encoder

Each emoji carries ten bits, so five input bytes become four visible symbols—fewer characters than Base64 for the same payload, even though each glyph is multi-byte under the hood. This capability encodes plain UTF-8 text to Ecoji (defaulting to version 2 with trimmed padding) and decodes either Ecoji version 1 or version 2 back to text, rejecting unknown or mixed-version emoji sequences with a clear invalid input error.

Encode text to Ecoji V2 (or V1) emojis

Send a JSON body with the required string field text set to the plain message you want to carry, and leave mode at its default encode or set mode to encode explicitly. Set version to 2 (the default) for modern paste payloads, or version to 1 when you must interoperate with older Ecoji V1-only tools. Optional aliases input, value, and s are accepted for the text field, and direction, op, or action for mode, so generated clients from older form names still work. The response always includes result with the Ecoji string, mode equal to encode, version as v1 or v2, emoji_count as the number of emoji code points produced, and bytes as the UTF-8 length before encoding so tests can assert payload size.

Decode Ecoji emojis and report invalid input

Set mode to decode and put an Ecoji emoji string in text. Fill padding (the coffee emoji) and the special last-byte padding glyphs reconstruct short final blocks so one, two, three, or four residual bytes decode without guesswork. Empty Ecoji input, padding in the first position, truncated groups under V1 rules, and unknown emojis are all hard errors. Newlines and carriage returns are ignored so multi-line pastes still work, but any code point outside the Ecoji data alphabet and padding set causes an immediate invalid_input failure with a message that names the offending character. The decoder accepts both Ecoji V1 and V2: symbols that appear only in one version set the expected version for the rest of the payload, and a later symbol exclusive to the other version is rejected as mixed-version corruption. After the bytes are recovered they are interpreted as UTF-8 with a fatal decoder: illegal byte sequences raise invalid_input instead of inserting replacement characters that would corrupt downstream displays. Successful decode returns result as the recovered string, mode decode, version v1 or v2, emoji_count for the non-newline symbols in the input, and bytes as the decoded UTF-8 length. Validation failures are not charged on the prepaid API, so probing a suspicious paste is cheap for operators and safe for end users who only need a clear diagnosis.

API usage, pricing, workflows, and practical limits

Call the free in-browser Ecoji emoji encoder for classroom demos, support playbooks, and one-off conversions without installing the Go reference tool or language-specific packages. A typical workflow encodes a short configuration fragment or ticket identifier for a chat channel that mangles Base64 punctuation, then decodes on the receiving service with mode decode and asserts that bytes match the original length. Prefer Ecoji when search intent is literally emoji transfer encoding or Ecoji encode decode; prefer Base64 or Base58 when the channel is pure ASCII and emoji fonts are unreliable. Use the prepaid KIT API when a backend, serverless function, or SDK needs the same encode or decode step under balance at $0.002 per successful item; failed validation never consumes balance after the engine rejects the request. Authors shipping SDKs can map the result field straight into a copy button, while mode, version, and emoji_count labels make screenshots and OpenAPI examples self-explanatory for readers who are new to base-1024 emoji encodings.