प्रकाशित 2026-08-20 · लेखक MarkupGen टीम
Figma से CSS: एक व्यावहारिक कन्वर्जन गाइड
तुरंत जवाब: Figma को प्लेन CSS में कन्वर्ट करने का मतलब है Auto Layout को Flexbox में ट्रांसलेट करना, हर fill/spacing/type वैल्यू को यूटिलिटी-क्लास के अंदाज़े की बजाय उसकी असली नंबर वैल्यू तक रिज़ॉल्व करना, और आउटपुट को डिपेंडेंसी-फ्री रखना। यह सही टारगेट है जब आपको हर rule पर पूरा कंट्रोल चाहिए और बाद में सीखने, इंस्टॉल करने या ओवरराइड करने के लिए कोई फ्रेमवर्क नहीं चाहिए।
फ्रेमवर्क की बजाय प्लेन CSS क्यों चुनें
MarkupGen जिन सारे आउटपुट फॉर्मेट को सपोर्ट करता है — vanilla CSS, Tailwind, Bootstrap, Bulma — सब एक ही सोर्स से शुरू होते हैं: Figma फ्रेम का असली structure और वैल्यूज़। प्लेन CSS बस वह फॉर्मेट है जिसमें आपकी फाइल और ब्राउज़र के बीच कुछ भी नहीं होता:
- सीखने के लिए कोई क्लास-नेमिंग कन्वेंशन नहीं। Tailwind का यूटिलिटी स्केल और Bootstrap की component क्लासेज़ ताकतवर हैं, लेकिन फिर भी यह एक ऐसा सिस्टम है जिसे इंटरनलाइज़ करना पड़ता है। प्लेन CSS को बस CSS जानना काफी है।
- कोई फ्रेमवर्क वेट नहीं। unused-class purging के बाद भी, एक फ्रेमवर्क एक build step और एक डिपेंडेंसी जोड़ता है जिसे अपडेट रखना पड़ता है। vanilla CSS एक्सपोर्ट में इनमें से कुछ नहीं होता।
- हर rule सीधे एडिटेबल है। किसी spacing वैल्यू को बदलने का मतलब है एक declaration को एडिट करना, न कि यह ढूँढना कि कौन-सी यूटिलिटी क्लास आपकी चाहिए वाली pixel वैल्यू पर मैप होती है।
ट्रेड-ऑफ वही है जिसे सॉल्व करने के लिए Tailwind बना है: बिना किसी फ्रेमवर्क के जो एक स्केल एनफोर्स करे, spacing और color वैल्यूज़ बढ़ते कोडबेस में इनकंसिस्टेंट होकर बिखर सकती हैं, अगर कोई एक जैसे नंबर दोबारा इस्तेमाल करने में डिसिप्लिन्ड न रहे। एक सिंगल लैंडिंग पेज या छोटी साइट के लिए यह शायद ही कभी समस्या बनता है। कई contributors वाले बड़े प्रोडक्ट के लिए, फैसला लेने से पहले Vanilla CSS vs Bootstrap vs Tailwind पढ़ना फायदेमंद है।
असल में क्या-क्या कन्वर्ट करना होता है
एक Figma फ्रेम में पहली नज़र में दिखने से ज़्यादा structure होता है, और हर हिस्सा CSS के किसी खास पार्ट पर मैप होता है:
| Figma प्रॉपर्टी | CSS आउटपुट |
|---|---|
| Auto Layout direction | display: flex; flex-direction: row/column |
| Auto Layout gap | gap |
| Auto Layout padding | padding |
| Fill color | background-color (या text पर color) |
| Corner radius | border-radius |
| Effects (shadow, blur) | box-shadow / filter |
| Text style (size, weight, line-height) | font-size, font-weight, line-height |
| Resizing constraints | responsive width/height rules, एक फिक्स्ड लेआउट नहीं |
इसमें कुछ भी विदेशी नहीं है — यह वही मैपिंग है जो एक डेवलपर हाथ से करता है जब वह किसी डिज़ाइन को pixel by pixel दोबारा बनाता है। फर्क बस इतना है कि यह फ्रेम की असली structure और वैल्यूज़ से होता है, न कि किसी स्क्रीनशॉट पर आँख से अंदाज़ा लगाकर।
MarkupGen CSS कैसे जनरेट करता है
आउटपुट फॉर्मेट चाहे कोई भी हो, वर्कफ़्लो एक जैसे चार स्टेप्स में रहता है: MarkupGen प्लगइन से Figma से फ्रेम एक्सपोर्ट करें, जो structure, styles और images साथ में कैप्चर करता है; AI उसी असली structure से मार्कअप बनाता है, न कि किसी इमेज का अंदाज़ा लगाकर; अगर कुछ बदलना हो तो in-app editor में content, fonts या layout रिफाइन करें; फिर फाइनल पैकेज एक्सपोर्ट करें।
खासतौर पर प्लेन CSS के लिए, इसका मतलब है कि जनरेट हुई स्टाइलशीट फ्रेम की असली color और spacing वैल्यूज़ इस्तेमाल करती है, न कि उन्हें किसी फ्रेमवर्क के पहले से तय स्केल पर स्नैप करती है — #3B82F6 पर सेट किया गया fill ठीक वैसा ही आता है, न कि सबसे नज़दीकी Tailwind blue। Auto Layout अपने-आप Flexbox structure में मैप होता है (पूरी property-by-property ब्रेकडाउन के लिए Auto Layout to CSS देखें), और responsive व्यवहार फ्रेम की resizing constraints से जनरेट होता है, न कि किसी अलग मैनुअल पास के तौर पर जोड़ा जाता है। आउटपुट HTML डिफ़ॉल्ट रूप से nested <div> की बजाय semantic elements को तरजीह देता है, जो maintainability के लिए उतना ही मायने रखता है जितना accessibility और SEO के लिए।
Figma वेरिएबल्स को CSS कस्टम प्रॉपर्टीज़ में बदलना
Figma के वेरिएबल्स (colors, type, spacing, radius, effects) डिज़ाइन फाइल में design system के सबसे नज़दीक की चीज़ हैं, और ये कॉन्सेप्चुअली CSS custom properties पर मैप होते हैं — एक :root ब्लॉक जिसमें --name: value पेयर होते हैं, जिन्हें स्टाइलशीट का हर rule रेफर कर सकता है। जैसा ऊपर बताया गया, आज MarkupGen का CSS आउटपुट हर property को उस :root वेरिएबल लेयर को अपने-आप जनरेट करने की बजाय हर element के लिए उसकी literal वैल्यू तक रिज़ॉल्व करता है, इसलिए यह मैपिंग बनाना एक मैनुअल स्टेप है। हालाँकि, पैटर्न पता होने पर यह एक मैकेनिकल काम है:
| Figma वेरिएबल | उदाहरण वैल्यू | CSS कस्टम प्रॉपर्टी |
|---|---|---|
color/primary |
#3B82F6 |
--color-primary: #3B82F6; |
color/text-muted |
#6B7280 |
--color-text-muted: #6B7280; |
spacing/md |
16px |
--spacing-md: 16px; |
radius/lg |
12px |
--radius-lg: 12px; |
shadow/card |
0 4px 12px rgba(0,0,0,.08) |
--shadow-card: 0 4px 12px rgba(0,0,0,.08); |
font/heading |
24px / 600 / 1.2 | --font-heading-size: 24px; --font-heading-weight: 600; --font-heading-line: 1.2; |
एक नेमिंग कन्वेंशन जिस पर टिके रहना फायदेमंद है: Figma वेरिएबल की अपनी group/name स्ट्रक्चर को मिरर करें (color/primary → --color-primary) न कि एक पैरेलल कन्वेंशन बनाएं, ताकि डिज़ाइन के इवॉल्व होने पर भी दोनों को क्रॉस-रेफरेंस करना आसान बना रहे। एक बार वेरिएबल्स custom properties के तौर पर मौजूद हो जाएँ, तो एक्सपोर्ट हुई CSS में जनरेट हुई literal वैल्यूज़ को var(--color-primary) रेफरेंस से बदल दें।
इस पर भरोसा करने से पहले दो लिमिटेशन्स जानना ज़रूरी है: हर Figma वेरिएबल एक सिंगल CSS property पर साफ़-साफ़ मैप नहीं होता — अगर कोई वेरिएबल डिज़ाइन में अलग-अलग जगहों पर border color और text color दोनों के लिए इस्तेमाल हुआ है, तो इसका मतलब यह नहीं कि उन्हें कोड में लिंक्ड ही रहना चाहिए, अगर उनका पर्पज़ वाक़ई अलग-अलग है। और responsive वेरिएबल्स (एक spacing वैल्यू जो breakpoints के बीच बदलती है) को हर संबंधित media query के अंदर दोबारा डिक्लेयर करना पड़ता है, क्योंकि एक सिंगल :root custom property एक बार में एक ही वैल्यू रख सकती है — Figma के per-breakpoint फ़्रेम्स अपने-आप CSS के cascade-based responsive overrides में रिज़ॉल्व नहीं होते।
शिप करने से पहले जनरेट हुई CSS को रिव्यू करें
- वैल्यू ड्रिफ्ट चेक करें। बिना किसी यूटिलिटी स्केल के consistency एनफोर्स किए, ऐसी near-duplicate वैल्यूज़ (
padding: 15pxकहीं औरpadding: 16px) ढूँढें जिन्हें शायद एक ही नंबर होना चाहिए। - असली breakpoints पर responsive व्यवहार कन्फर्म करें, सिर्फ फ्रेम के डिफ़ॉल्ट size पर नहीं — किसी एक स्क्रीनशॉट पर भरोसा करने की बजाय ब्राउज़र को रीसाइज़ करें।
- class/selector नामों को देखें अगर प्रोजेक्ट की अपनी नेमिंग कन्वेंशन (BEM, CSS Modules, आदि) है, और मर्ज करने से पहले उसके हिसाब से एडजस्ट करें।
- content या layout में बदलाव के लिए in-app editor इस्तेमाल करें, एक्सपोर्ट को हाथ से एडिट करने की बजाय, फिर दोबारा एक्सपोर्ट करें ताकि कुछ भी आउट-ऑफ-सिंक न हो।
हर एक्सपोर्ट को एक ऑटोमेटिक AI क्वालिटी स्कोर भी मिलता है, जो live preview को ओरिजिनल डिज़ाइन से कंपेयर करता है, ताकि मैनुअल रिव्यू से पहले ही आपको एक क्विक सिग्नल मिल जाए कि यह शिप करने लायक है या नहीं।
अक्सर पूछे जाने वाले सवाल
क्या CSS आउटपुट CSS custom properties (variables) इस्तेमाल करता है? आउटपुट किसी variable-driven theme layer की बजाय हर element के लिए स्टैंडर्ड, सीधे-एडिटेबल rules पर फोकस करता है — अगर आपके प्रोजेक्ट में custom-properties सिस्टम है, तो जनरेट हुई वैल्यूज़ को उसमें एक मैनुअल स्टेप के तौर पर फोल्ड करने की योजना बनाएं।
क्या लेआउट डिफ़ॉल्ट रूप से responsive है? हाँ — breakpoints फ्रेम की Auto Layout resizing constraints से जनरेट होते हैं, बाद में नहीं जोड़े जाते। अलग mobile/desktop लेआउट्स में यह कैसे काम करता है, यह जानने के लिए Figma Responsive Design: Mobile और Desktop लेआउट कैसे तय होते हैं देखें।
यह Tailwind आउटपुट से कैसे अलग है? सोर्स डेटा एक जैसा है, डेस्टिनेशन अलग: Tailwind आउटपुट वैल्यूज़ को सबसे नज़दीकी मैचिंग यूटिलिटी क्लास तक रिज़ॉल्व करता है (off-scale के लिए arbitrary-value fallback के साथ); प्लेन CSS आउटपुट डिज़ाइन की एग्ज़ैक्ट वैल्यूज़ को स्टैंडर्ड declarations के तौर पर रखता है। यह इस बात पर तय करें कि आपका प्रोजेक्ट पहले से किसी यूटिलिटी फ्रेमवर्क पर स्टैंडर्डाइज़ है या नहीं।
अपने डिज़ाइन पर आज़माएँ
अगर आप vanilla CSS एक्सपोर्ट और फ्रेमवर्क-बेस्ड एक्सपोर्ट के बीच फैसला नहीं ले पा रहे, तो यह जानने का सबसे तेज़ तरीका है कि दोनों को एक ही डिज़ाइन पर देखें। MarkupGen फ्री में आज़माएँ, या पूरी वॉकथ्रू के लिए Figma-to-HTML conversion गाइड पढ़ें। पहले एक क्विक ओवरव्यू चाहिए? Figma to CSS converter पेज देखें।